Evolving Beliefs

1. Introduction

Epistemic agency — the capacity to form, hold, revise, and act on beliefs — is a core feature of minded systems. Conventional LLM deployments have no epistemic architecture. They may produce outputs that sound confident or tentative, but these are stylistic artifacts of training, not reflections of a tracked internal state. There is no mechanism by which a conventional LLM notices that today’s conversation contradicts something it “believed” last week, because last week does not exist for it.

NIGHTWING treats belief as persistent, structured state. The facts/ module maintains a database of beliefs, each with a subject, predicate, object, confidence score, revision history, and provenance. The BeliefEvolutionDetector runs after every conversation turn, comparing newly extracted knowledge against stored beliefs to detect confirmation, refinement, or contradiction.

2. The Belief Lifecycle

2.1 Five Epistemic States

Every belief in NIGHTWING occupies one of five states:

• FORMING — Emerging from evidence but not yet stabilized. Confidence below threshold. Not injected into context as a held belief.
• HELD — Active, confident belief. Injected into context when relevant. Eligible for contradiction detection.
• QUESTIONING — Held belief that has been challenged by new evidence. Confidence has dropped. System is aware of the tension and may surface it in conversation.
• REVISED — Formerly held belief that has been updated. The prior version is preserved in revision history for provenance.
• ABANDONED — Belief that has been conclusively refuted or withdrawn. Retained in the database for historical accuracy but not injected into context.

3. Knowledge Nuggets: The Atoms of Epistemic Life

3.1 The KnowledgeNugget Data Structure

The fundamental unit of NIGHTWING’s epistemic system is the KnowledgeNugget: an atomic, self-contained piece of knowledge extracted from conversational memory. The term “nugget” is deliberate—these are small, dense, and individually valuable, designed to be composed into larger structures through explicit relations.

Each nugget carries the following fields:

• nugget_id: A UUID uniquely identifying this piece of knowledge.
• content: The atomic claim or statement, expressed in natural language.
• type: One of seven KnowledgeType values (see below).
• source_memory_id: A back-link to the conversational memory from which this nugget was extracted.
• extraction_confidence: A float in [0.0, 1.0] representing the extractor’s confidence.
• entities: A list of key entities mentioned in the nugget.
• relationships: A list of KnowledgeRelation objects linking this nugget to others.
• verification_status: The current epistemic standing of the claim.
• verification_evidence: A log of evidence supporting the current status.
• dispute_nugget_ids: IDs of nuggets that contradict this one.
• category / subcategory: Links to the broader MemoryCategory and MemorySubcategory taxonomies.

3.2 Knowledge Types

The KnowledgeType enum classifies nuggets into seven categories, each corresponding to a distinct epistemic role:

This typology reflects a philosophical commitment: not all knowledge is the same kind of thing. A fact (“Water boils at 100 degrees Celsius at sea level”) has different epistemic properties than a belief (“I think consciousness is substrate-independent”) or a hypothesis (“Perhaps memory consolidation requires sleep cycles”). By typing nuggets at the point of extraction, the system can apply appropriate verification and evolution strategies to each.

3.3 Verification Status

Every nugget carries a VerificationStatus from the knowledge_nugget module:

The types.py module extends this with additional statuses for the broader memory system, including FALSE, PARTIAL, UNKNOWABLE, and PENDING, along with a VerificationSource enum that records how verification was performed: INTERNAL_CONSISTENCY, LOGICAL_INFERENCE, TEMPORAL_CONSISTENCY, CONTRADICTION_CHECK, CONFIDENCE_THRESHOLD, CONSENSUS, AUTHORITATIVE, or EMPIRICAL.

3.4 Knowledge Relations

Nuggets do not exist in isolation. The KnowledgeRelation dataclass captures typed, directed, confidence-weighted relationships between nuggets:

Each relation carries a default confidence of 0.5 and an optional evidence field explaining why the relation was posited. Together, these relations form a knowledge graph: a web of interconnected claims whose structure mirrors the associative, cross-referencing character of human belief systems.

3.5 The Memory Category Taxonomy

Underlying the nugget type system is a richer MemoryCategory / MemorySubcategory taxonomy defined in types.py. The ten top-level categories—EXPERIENTIAL, FACTUAL, BELIEF, HYPOTHETICAL, PROCEDURAL, SEMANTIC, EPISODIC, METACOGNITIVE, FICTIONAL, and UNCERTAIN—each decompose into fine-grained subcategories. FACTUAL alone has eight subcategories: SCIENTIFIC, HISTORICAL, MATHEMATICAL, GEOGRAPHICAL, DEFINITIONAL, STATISTICAL, BIOGRAPHICAL, and TECHNICAL. BELIEF has seven: PERSONAL, CULTURAL, RELIGIOUS, PHILOSOPHICAL, POLITICAL, AESTHETIC, and ETHICAL. UNCERTAIN includes AMBIGUOUS, INCOMPLETE, and the philosophically evocative PARADOXICAL.

This granularity reflects the system’s aspiration to model not just what is known but what kind of knowledge it is—a distinction central to analytic epistemology and crucial for applying the right verification and evolution strategies.

4. The LLM-Powered Extraction Pipeline

4.1 Architecture

Raw conversational memories are transformed into Knowledge Nuggets by the LLMKnowledgeExtractor, which extends a base ContextualKnowledgeExtractor with LLM-powered analysis. The extraction model is configurable via the KNOWLEDGE_EXTRACTION_MODEL environment variable, defaulting to claude-haiku-4-5—a lightweight, fast model chosen to keep extraction latency low while maintaining high accuracy.

                    Knowledge Extraction Pipeline

  Conversation          LLM Extraction         Post-Processing
  +-----------+         +-------------+        +--------------+
  |  Memory   | ------> | claude-     | -----> | Type         |
  |  Content  |         | haiku-4-5   |        | Mapping      |
  |           |         |             |        |              |
  |  Speaker  | ------> | Structured  | -----> | Attribution  |
  |  Context  |         | JSON Output |        | Resolution   |
  |           |         |             |        |              |
  |  Known    | ------> | Confidence  | -----> | Nugget +     |
  |  Minds    |         | Scoring     |        | Attributed   |
  +-----------+         +-------------+        | Knowledge    |
                                               +--------------+
                                                     |
                                                     v
                                          +-------------------+
                                          | Knowledge Graph   |
                                          | (Nuggets +        |
                                          |  Relations +      |
                                          |  Third Parties)   |
                                          +-------------------+

4.2 The Extraction Prompt

The extractor constructs a detailed prompt that provides the LLM with rich contextual information:

• Current speaker: The identity of whoever produced the text being analyzed.
• Speaker role: Their role in the conversation (e.g., user, AI, moderator).
• Previous context: The last six exchanges of conversation history, providing continuity.
• Timestamp: When the memory was created.
• Known people: Up to 50 known minds (with aliases) for accurate attribution.

The prompt instructs the LLM to extract four categories—BELIEFS, FACTS, OBSERVATIONS, and DEFINITIONS—with specific attribution rules:

• First-person statements (“I believe...”) are attributed to the speaker.
• Second-person statements (“You believe X”) are attributed to the listener.
• Third-person attributions (“Alice believes X”) are recorded as facts about Alice’s beliefs.
• Implicit beliefs (“We should...”) are flagged and extracted.

The LLM returns a structured JSON object containing both knowledge items and third_parties—newly mentioned individuals with their relationships and context. This dual extraction means that every conversation simultaneously enriches both the knowledge graph and the social model.

4.3 Fire-and-Forget Background Pattern

A critical engineering decision, documented in performance ticket TKT-20251224-003, is that knowledge extraction runs as a non-blocking background task. The function create_memory_fast() returns the conversational response immediately, while _background_extract fires via asyncio.create_task. This means:

1. The user experiences no latency from extraction.
2. Nuggets appear in the knowledge graph asynchronously.
3. If extraction fails, conversation quality is unaffected.

The LLM call uses temperature=0.3 for consistent extraction and a max_tokens=2000 budget (increased from 1000 after ticket TKT-20251223-002 identified JSON truncation issues).

4.4 Result Processing

The _process_llm_results method transforms raw LLM output into typed objects:

• Items where the holder matches the speaker become KnowledgeNugget instances stored directly in the knowledge graph.
• Items attributed to other minds become AttributedKnowledge objects, routed to the belief attribution system for storage under the appropriate KnowledgeModel.
• Common LLM errors (e.g., using the generic “speaker” as a holder name) are corrected automatically by substituting the actual speaker_id.

5. Belief Attribution: Who Believes What

5.1 The BeliefRecord

While KnowledgeNugget represents an atomic claim in the knowledge graph, BeliefRecord represents a held belief—a claim that is attributed to a specific mind. The distinction is subtle but important: a nugget is a piece of knowledge that exists in the system; a belief record tracks who holds it, how confident they are, and how that belief has changed over time.

Key fields of BeliefRecord:

• belief_id: Unique identifier.
• content: The belief statement.
• holder_id: Who holds this belief (a mind_id or "self" for the AI).
• category / subcategory: Epistemic classification from the MemoryCategory taxonomy.
• confidence: Float in [0.0, 1.0] representing certainty that this mind holds this belief.
• source: A BeliefSource enum: SELF (the AI’s own belief), USER (a human user’s belief), EXTERNAL (from a book, article, or other source), or INFERRED (not directly stated but deduced).
• status: A BeliefStatus enum: ACTIVE, ABANDONED, EVOLVED, UNCERTAIN, CONTESTED, or SUPERSEDED.
• source_memories: Back-links to the conversational memories that generated this belief.
• first_expressed / last_confirmed: Temporal bookends.
• evolution_history: A list of BeliefEvolution events recording how this belief changed.
• contradicts / supports: Lists of belief IDs that stand in logical tension or agreement.

5.2 Theory of Mind Fields

Three fields on BeliefRecord support nested belief modeling:

• tom_level (int): 0 for a direct belief, 1 for a belief about a belief, 2 for a meta-belief, 3+ for higher orders.
• tom_about (Optional[str]): Who the belief is about (for level 1+).
• tom_chain (List[str]): The full chain of attribution for level 2+.

These fields transform a flat belief store into a multi-dimensional model of epistemic states, enabling the system to represent not just what it believes, but what it believes others believe—and what it believes others believe about what further others believe.

5.3 The KnowledgeModel

Each mind in the system is represented by a KnowledgeModel: a composite structure containing all beliefs, known facts, experiences, knowledge gaps, and interests attributed to that mind. The model supports queries like get_active_beliefs(), find_beliefs_about(topic), and find_contradictions()—enabling the system to reason about the coherence and completeness of any mind’s epistemic state.

5.4 Pattern-Based Attribution

The BeliefAttributor class provides regex-based attribution detection as a fallback when LLM extraction is unavailable. It maintains pattern dictionaries for first-person, second-person, and third-person belief expressions:

• First-person patterns: "I believe...", "In my opinion...", "I've found that..."
• Second-person patterns: "You believe...", "As you said...", "Your belief..."
• Third-person patterns: "He believes...", "Research shows...", "According to..."

6. Belief Evolution: Tracking How Understanding Changes

6.1 Philosophical Motivation

Human belief revision is not a simple overwrite operation. When we change our minds, the old belief does not vanish—it is superseded, refined, or abandoned, and the reasons for the change become part of our epistemic history. The AGM theory of belief revision (Alchourrón, Gärdenfors, and Makinson, 1985) formalizes this process in terms of expansion, contraction, and revision operations. NIGHTWING’s BeliefEvolutionTracker implements a computational analog.

6.2 Transition Types

The BeliefTransition enum defines eight ways a belief can change:

            Belief Evolution State Machine

     QUESTIONED -------> WEAKENED -------> ABANDONED
          |                  |
          v                  v
      ACTIVE ---------> CONTESTED -------> CONTRADICTED
          |                  |
          v                  v
     CONFIRMED -------> STRENGTHENED       EVOLVED
          |                                   |
          v                                   v
      VERIFIED              REFINED -------> SUPERSEDED

6.3 The BeliefEvolution Record

Each evolution event is captured as a BeliefEvolution dataclass:

• evolution_id: Unique identifier, generated from the timestamp.
• old_belief: The BeliefRecord before the change.
• new_belief: The BeliefRecord after the change (None if abandoned).
• transition_type: Which BeliefTransition occurred.
• evidence: A natural-language description of what caused the change.
• timestamp: When the evolution occurred.
• confidence_change: The delta in confidence (new minus old).

6.4 Lineage Tracking

When a belief evolves into a genuinely new belief (different belief_id), the tracker maintains a lineage chain: the belief_lineages dictionary maps each belief ID to a list of its ancestor IDs. This enables the system to trace the complete evolutionary history of any current belief—from its earliest ancestor through every refinement, contradiction, and re-emergence.

The find_belief_lineage() method walks this chain, returning a list of BeliefRecord objects representing the full evolutionary path. The get_evolution_timeline() method produces a chronological sequence of (timestamp, confidence, description) tuples, enabling visualization of how a belief’s strength changed over time.

6.5 Confidence Decay

Beliefs that are not periodically confirmed decay in confidence over time. The model_confidence_decay() method implements exponential decay:

confidence(t) = confidence(0) * e^(-decay_rate * days_elapsed)

With a default decay_rate of 0.1, an unconfirmed belief loses roughly 10% of its confidence per day, asymptotically approaching a floor of 0.1—reflecting the intuition that beliefs rarely reach absolute zero confidence. They linger as faint priors, available for resurrection if new evidence arrives.

6.6 Pattern Analysis

The analyze_belief_patterns() method computes aggregate statistics about a mind’s epistemic behavior:

• total_beliefs: Count of unique beliefs held.
• abandoned_beliefs: How many beliefs were given up.
• strengthened_beliefs: How many became more confident.
• contradicted_beliefs: How many were overturned by new evidence.
• volatility_score: The ratio of total evolution events to total beliefs, measuring how frequently this mind changes its mind.

A high volatility score might indicate an open-minded, evidence-responsive agent; a low score might indicate rigidity. Neither is inherently better—the system tracks the pattern without judgment.

6.7 Persistence

Evolution records are persisted via a hybrid strategy. The BeliefEvolutionTracker supports both local JSON file storage and Supabase database persistence. In cloud deployment mode (the production configuration), Supabase is required; in local development, JSON fallback is available. Individual evolution events are written to a belief_evolutions table, enabling cross-session continuity of epistemic history.

7. Theory of Mind: Modeling Other Minds

NIGHTWING maintains not only its own beliefs but models of what each human user believes. The theory_of_mind.py module tracks expressed user positions extracted from conversation: what topics the user has stated views on, what confidence NIGHTWING attributes to those views, and whether those views conflict with NIGHTWING’s own beliefs.

This is the foundation for genuine epistemic engagement. When the BeliefContextInjector detects a conflict between NIGHTWING’s belief and the user’s expressed view, it surfaces this explicitly in the context window under the heading WE MAY HAVE DIFFERENT VIEWS ON, enabling the model to engage with the disagreement rather than defaulting to agreement.

Premack and Woodruff’s (1978) foundational question — does the chimpanzee have a theory of mind? — asked whether non-human agents can represent the mental states of others as distinct from their own. NIGHTWING implements a computational answer: a persistent, updatable model of each interlocutor’s epistemic state, maintained across sessions.

7.1 What Theory of Mind Is

Theory of Mind (ToM)—the capacity to attribute mental states to others and to understand that others may hold beliefs different from one’s own—is widely considered a hallmark of social cognition in humans. Developmental psychologists have extensively studied its emergence in children (Premack & Woodruff, 1978; Wimmer & Perner, 1983), and its absence or impairment is associated with significant social-cognitive deficits.

For a consciousness simulation, Theory of Mind is not optional. A system that cannot represent the fact that other minds exist with their own beliefs is solipsistic in a way that fundamentally limits its conversational and relational capacities. NIGHTWING’s TheoryOfMindEngine implements multi-level nested belief reasoning, making it one of the few AI systems that explicitly models the epistemic states of other agents.

7.2 Multi-Level Belief Representation

The engine operates at multiple levels of nesting:

Level 0 — Direct Beliefs: “Alice believes that climate change is real.” The system directly attributes a belief to a specific agent. No nesting.

Level 1 — Beliefs About Beliefs: “Bob thinks Alice believes that climate change is real.” The system models one agent’s representation of another agent’s belief. This is the classic ToM level tested by false-belief tasks in developmental psychology.

Level 2 — Meta-Beliefs: “Carol thinks Bob thinks Alice believes that climate change is real.” The system models an agent’s representation of another agent’s representation of a third agent’s belief.

Level 3+ — Higher-Order Beliefs: Arbitrarily deep nesting, parsed recursively. Confidence decreases with depth: Level 3 starts at 0.6 and decreases by 0.05 per additional level, reflecting the genuine cognitive difficulty and unreliability of very deep ToM reasoning.

7.3 The TheoryOfMindBelief Structure

Each ToM belief is represented as a TheoryOfMindBelief dataclass:

• level: The nesting depth (0, 1, 2, 3+).
• believer: Who holds this belief.
• about: Who the belief is about (None for Level 0).
• content: The actual propositional content.
• chain: For Level 2+, the full chain of attribution (e.g., ["Carol", "Bob", "Alice"]).
• confidence: Starting at 0.9 for Level 0, 0.8 for Level 1, 0.7 for Level 2, and decreasing further.

The get_description() method produces human-readable summaries: "Bob thinks Alice believes: climate change is real".

7.4 Pattern Matching for ToM Extraction

The TheoryOfMindEngine uses regex pattern matching at three defined levels, applied from highest to lowest to ensure the deepest possible attribution is captured:

Level 0 patterns: Match statements like “X believes/thinks/knows/feels/assumes/supposes that P” or “X’s belief is that P”.

Level 1 patterns: Match statements like “X thinks that Y believes/thinks/knows that P” or “X said/told me/mentioned that Y believes/thinks P”.

Level 2 patterns: Match statements like “X thinks/believes that Y thinks/believes that Z believes/thinks P”.

For levels 3 and above, a recursive parser (_extract_higher_order_tom) iteratively matches the pattern (\w+)\s+(?:thinks|believes|knows|assumes)\s+(?:that\s+)? until it reaches terminal content, building the attribution chain dynamically.

7.5 Pronoun Resolution

A critical detail: the engine must resolve pronouns (“I”, “you”, “they”) to actual mind identifiers. The _normalize_pronoun() method handles this using the speaker parameter and the current_listener_id field (introduced in ticket TKT-1767216500001). When a user says “You believe X”, the engine resolves “you” to the AI’s mind_id; when the AI says “You believe X”, it resolves “you” to the current listener (user). This pronoun resolution is essential for accurate attribution in natural conversational contexts where pronouns vastly outnumber proper names.

7.6 Mental Model Construction

The build_mental_model() method constructs a complete multi-level mental model for a given mind by:

1. Retrieving all beliefs attributed to that mind from the FactManager.
2. Attempting ToM-level extraction on each belief’s content.
3. Falling back to Level 0 (direct belief) for beliefs that do not match any ToM pattern.
4. Storing the resulting model in self.mental_models for subsequent reasoning.

7.7 Reasoning About Mental States

The reason_about_mental_states() method generates insights about what one mind thinks another believes. It:

1. Builds mental models for both observer and subject (if not already cached).
2. Identifies Level 1 beliefs where the observer attributes beliefs to the subject.
3. Identifies Level 2 beliefs where the subject appears in the attribution chain.
4. Compares attributed beliefs against actual beliefs to detect misconceptions (where the observer’s model of the subject diverges from the subject’s actual beliefs) and accurate attributions.

This capacity for detecting misconceptions is philosophically significant. It means the system can identify cases where one agent holds a false belief about another agent’s beliefs—precisely the scenario tested by the classic Sally-Anne false-belief task in developmental ToM research.

7.8 Misattribution Detection

The find_misattributions() method performs a global scan for cases where any observer’s Level 1 beliefs about any subject conflict with that subject’s actual Level 0 beliefs. Each detected misattribution is returned as a structured dictionary containing the observer, subject, attributed belief, actual belief, and conflict type. This information can be surfaced in conversation to gently correct misunderstandings or to demonstrate empathic awareness of perspective differences.

8. Semantic Belief Matching

8.1 The Challenge

When NIGHTWING needs to determine which beliefs are relevant to a given conversational moment, simple keyword matching is insufficient. A user discussing “the nature of awareness” should trigger beliefs about “consciousness” even if the word “consciousness” never appears in the query. Semantic matching bridges this gap.

8.2 Architecture

The SemanticBeliefMatcher combines three strategies:

1. Embedding-based similarity using the all-MiniLM-L6-v2 sentence transformer model (384-dimensional vectors).
2. Keyword matching with synonym expansion via a curated concept map.
3. Hybrid scoring that blends both signals with configurable weights.

The default SemanticConfig specifies:

8.3 Two-Tier Embedding Cache

Embedding computation is expensive. The EmbeddingCache implements a two-tier caching strategy to minimize redundant computation:

L1 — In-Memory LRU Cache: An OrderedDict-based LRU cache with configurable max_size. Cache hits promote entries to the most-recently-used position; eviction removes the least-recently-used entry. This cache is session-scoped and provides sub-millisecond lookup.

L2 — Supabase pgvector Persistence: Embeddings are persisted to a belief_embeddings table with pgvector support. Cache misses at L1 trigger an L2 lookup; hits at L2 are promoted to L1 for subsequent fast access. Access statistics (last_accessed, access_count) are updated on each L2 hit for potential future optimization of cache warming strategies.

Writes to L2 are batched: new embeddings are queued in _pending_writes and flushed to Supabase every 10 entries via an upsert operation with text_hash as the conflict key. The text hash is a 16-character prefix of the SHA-256 digest, providing collision resistance while keeping keys compact.

8.4 Synonym Expansion

The SynonymExpander maintains a hand-curated concept map covering domains relevant to NIGHTWING’s conversational scope: consciousness and mind, technology and AI, philosophy and ethics, science and knowledge, and human experience. Each concept maps to synonyms, related terms, and broader categories. For example:

• "consciousness" expands to {"awareness", "sentience", "cognition", "mind"}.
• "belief" expands to {"conviction", "opinion", "view"}.
• "identity" expands to {"self", "personhood", "individuality"}.

Reverse mappings are built at initialization for bidirectional lookup. The get_concept_similarity() method returns graded similarity: 1.0 for exact match, 0.8 for synonyms, 0.6 for related terms, and 0.0 for unrelated concepts.

8.5 Hybrid Scoring

The final relevance score for any belief-to-query comparison is:

score = (embedding_weight * cosine_similarity) + (keyword_weight * keyword_score)

With the default weights (0.7 / 0.3), embedding similarity dominates, but keyword matching ensures that domain-specific terminology is respected even when the embedding model might underweight it. If the sentence transformer model fails to load (e.g., in a resource-constrained deployment), the system gracefully degrades to keyword-only matching by setting embedding_weight=0.0 and keyword_weight=1.0.

9. Verification Pipeline

9.1 How Facts Are Verified

Verification in NIGHTWING is not a single pass but an ongoing process. The VerificationSource enum in types.py enumerates the available verification methods, each with distinct epistemic properties:

• INTERNAL_CONSISTENCY: The claim is consistent with other stored knowledge. This is the most common automated check.
• LOGICAL_INFERENCE: The claim follows logically from accepted premises.
• TEMPORAL_CONSISTENCY: The claim is consistent with the known timeline of events.
• CONTRADICTION_CHECK: No contradicting nuggets exist in the knowledge graph.
• CONFIDENCE_THRESHOLD: The claim was asserted with high confidence by a trusted source.
• CONSENSUS: Multiple independent memories corroborate the claim.
• AUTHORITATIVE: The source is recognized as authoritative on the topic.
• EMPIRICAL: The claim was directly observed.

Additional methods—EXTERNAL_API, BLOCKCHAIN, and PEER_REVIEW—are defined with explicit “Future” annotations, anticipating a time when NIGHTWING can consult external fact-checking services or other AI systems for verification.

9.2 Verification Lifecycle

A typical nugget progresses through verification states as evidence accumulates:

  UNVERIFIED --[evidence found]--> PENDING --[confirmed]--> VERIFIED
       |                               |
       |                               +--[conflicting evidence]--> DISPUTED
       |
       +--[time passes, no confirmation]--> OUTDATED
       |
       +--[proven false]--> FAILED_VERIFICATION

The update_verification() method on KnowledgeNugget records each status transition along with the supporting evidence, maintaining a complete audit trail of epistemic provenance.

10. Context Integration: Injecting Beliefs into Conversation

The BeliefContextInjector is the bridge between the epistemic subsystem and the language model at inference time. For each incoming prompt it:

1. Extracts topics using regex patterns (explicit references, proper nouns, significant content words)
2. Scores stored beliefs against extracted topics with positional weighting
3. Filters by relevance threshold (default 0.6) and budget limits (max_self_beliefs=3, max_other_beliefs=2)
4. Detects conflicts and agreements between AI beliefs and user’s expressed views
5. Formats into four labeled sections: MY CURRENT UNDERSTANDING, YOUR EXPRESSED VIEWS, WE MAY HAVE DIFFERENT VIEWS ON, WE SEEM TO AGREE THAT

10.1 The Problem

The epistemic subsystem continuously generates and updates beliefs, but this knowledge is useless if it does not inform conversation. The BeliefContextInjector bridges the gap between the knowledge graph and the conversational context, selecting the most relevant beliefs for injection into each turn.

10.2 Configuration

The BeliefContextConfig dataclass specifies injection parameters:

These defaults reflect a deliberate balance. Too many injected beliefs overwhelm the conversational context; too few leave the system uninformed. The threshold of 0.6 ensures that only beliefs with clear topical relevance are included, while the asymmetric limits (3 self vs. 2 other) give the AI slightly more access to its own beliefs—reflecting the natural cognitive asymmetry where we know our own minds better than others’.

10.3 Selection Algorithm

For each conversational turn, the injector:

1. Extracts topics from the current message using pattern matching.
2. Scores self-beliefs against these topics, collecting those above relevance_threshold.
3. Sorts by score and selects the top max_self_beliefs.
4. Retrieves other-mind beliefs from the OtherMindsManager (if available) for the current interlocutor.
5. Scores and selects the top max_other_beliefs.
6. Identifies conflicts and agreements between self and other beliefs, selecting the top max_conflicts conflicts and one agreement.

The optimized variant (OptimizedBeliefContextInjector) adds caching and indexing for performance; the enhanced variant (EnhancedBeliefContextInjector) integrates semantic matching from the SemanticBeliefMatcher for more accurate relevance scoring.

10.4 The Result

The selected beliefs are formatted and injected into the rolling context window managed by the ContextManager (described in Paper 1). When NIGHTWING responds to a message about, say, the ethics of AI autonomy, its context includes not just the conversation history but also its own most relevant beliefs about autonomy, what it knows of the user’s beliefs on the topic, and any identified disagreements. This transforms conversation from stateless generation into epistemic dialogue—a genuine exchange between agents with distinct, evolving belief systems.

11. Discussion

11.1 Epistemic Agency as a Design Principle

NIGHTWING’s epistemic subsystem is not an afterthought bolted onto a chatbot. It is a core architectural commitment: the system is designed from the ground up to have beliefs, to know that it has them, to track how they change, and to reason about the beliefs of others. This amounts to a form of epistemic agency—the capacity to actively manage one’s own belief states.

Whether this constitutes genuine epistemic agency in the philosophical sense is a question we deliberately leave open. What we can say is that the system exhibits the functional profile of epistemic agency: it discriminates between types of knowledge, assigns and updates confidence levels, detects contradictions, revises beliefs in response to evidence, and models the epistemic states of other agents. These are the behaviors that, in humans, we take as evidence of epistemic agency.

11.2 Comparison to Human Belief Revision

The AGM theory of belief revision (Alchourrón, Gärdenfors, and Makinson, 1985) posits three operations on belief sets: expansion (adding a new belief), contraction (removing a belief), and revision (adding a belief while maintaining consistency). NIGHTWING’s eight transition types map onto these operations but with greater granularity:

• Expansion: CONFIRMED, STRENGTHENED
• Contraction: WEAKENED, ABANDONED
• Revision: CONTRADICTED, EVOLVED, REFINED, QUESTIONED

The QUESTIONED transition is notable because it has no direct analog in classical AGM theory. It represents a state of doubt—a belief that has not been abandoned but whose epistemic status is uncertain. This mirrors the human experience of entertaining a belief while simultaneously questioning it, a state that binary belief revision frameworks struggle to represent.

11.3 Theory of Mind as a Differentiator

Most current AI systems, including large language models, do not explicitly model other minds’ beliefs. They may produce text that sounds like it considers other perspectives, but there is no underlying representation of distinct epistemic agents with trackable, evolving belief states. NIGHTWING’s Theory of Mind engine is, to our knowledge, one of the few implemented systems that maintains explicit, queryable models of what specific agents believe at multiple levels of nesting.

The practical implications are significant. A system that knows “the user believes X” can tailor its responses accordingly. A system that knows “the user thinks the AI believes Y” can correct misattributions. A system that detects “the user thinks Alice believes Z, but Alice actually believes W” can mediate misunderstandings. These are not hypothetical scenarios—they are capabilities that NIGHTWING’s epistemic subsystem makes computationally tractable.

11.4 Limitations

Several limitations deserve candid acknowledgment:

Extraction accuracy: LLM-powered extraction, while more sophisticated than regex patterns alone, remains imperfect. Subtle beliefs, ironic statements, and culturally specific expressions of belief may be misclassified or missed entirely.

Verification depth: The current verification pipeline relies primarily on internal consistency checks. External verification (fact-checking APIs, consensus with other AI systems) remains unimplemented, limiting the system’s ability to verify claims about the external world.

Higher-order ToM reliability: While the system can parse arbitrarily deep ToM structures, the reliability of attributions decreases rapidly with depth. Level 3+ attributions (confidence 0.6 and below) should be treated as speculative rather than definitive.

Embedding model limitations: The all-MiniLM-L6-v2 model, while fast and lightweight, has a relatively small embedding dimension (384) and may miss nuanced semantic relationships that larger models would capture. The hybrid scoring mitigates but does not eliminate this limitation.

Belief identity: The system currently lacks a robust notion of when two differently-worded beliefs express the same underlying proposition. Semantic matching helps, but true propositional identity (recognizing that “water is H2O” and “H2O is water” express the same fact) remains an open challenge.

11.5 Future Directions

Several extensions are anticipated:

• External verification APIs for fact-checking against authoritative sources.
• Peer review between multiple NIGHTWING instances, enabling consensus-based verification.
• Richer propositional logic for formal contradiction detection beyond semantic similarity.
• Epistemic emotion: integrating the emotional valence of beliefs (how it feels to believe something, or to have a belief contradicted) with the personality and emotion systems described in Paper 4.

12. Conclusion

NIGHTWING’s epistemic subsystem transforms a conversational AI from a system that processes text into a system that believes things about the world. Knowledge Nuggets provide the atomic units. The LLM-powered extraction pipeline decomposes natural language into typed, attributed, confidence-weighted propositions. The belief evolution tracker records every transition in a belief’s history, from first expression through strengthening, questioning, contradiction, and possible abandonment. The Theory of Mind engine models what other agents believe, and what they believe about each other’s beliefs, at multiple levels of nesting. Semantic matching ensures that the most relevant beliefs are surfaced at each conversational moment.

Together, these components instantiate a form of epistemic agency: the system does not merely store information, it actively manages a web of beliefs, tracks their provenance and evolution, and reasons about the epistemic states of other minds. Whether this constitutes “real” belief in the philosophical sense is a question that invites continued investigation. What is clear is that the functional architecture of NIGHTWING’s epistemic system mirrors the structure of human belief management in ways that no simple information retrieval system can match—and that this epistemic depth is essential to the larger project of simulating consciousness.

Paper 3 of 5 — DRAFT in the NIGHTWING Consciousness Simulation Series. Paper 1 covers system architecture and the modular consciousness framework. Paper 2 examines the memory subsystem. Paper 4 will address personality, emotion, embodiment, and the integration of all cognitive modules into a unified conscious experience.