Implement WFGY Semantic Firewall for Enhanced Memory Reliability

[doobidoo]

Implement WFGY Semantic Firewall for Enhanced Memory Reliability

🎯 Executive Summary

Integrate the WFGY (Wan Fa Gui Yi - "All Principles Return to One") semantic firewall framework into MCP Memory Service to address critical failure modes in memory retrieval and reasoning. This enhancement provides real-time detection and recovery for 16 common RAG/LLM failure patterns while maintaining 100% backward compatibility.

🔴 Problem Statement

Current Limitations

The MCP Memory Service, while robust, faces several critical challenges that affect reliability and accuracy:

1. Semantic-Embedding Mismatch (Problem Side-loading the database #5)

   • ChromaDB/sentence-transformer embeddings may return high cosine similarity for semantically unrelated content
   • No validation layer between mathematical similarity and actual semantic relevance
   • Results in irrelevant memory retrievals that appear mathematically "correct"

2. Entropy Collapse in Long Sessions (Problem Add Database Merging Capabilities to MCP Memory Service #9)

   • Extended conversations cause attention mechanism degradation
   • Memory retrieval quality deteriorates progressively
   • No mechanism to detect or recover from attention entropy collapse

3. Logic Drift in Multi-Step Reasoning (Problem Implement Automated Backup System with Scheduling #3)

   • Reasoning chains lose coherence across multiple retrieval steps
   • No checkpointing or re-grounding mechanisms
   • Cumulative drift leads to completely off-topic responses

4. Lack of Real-Time Diagnostics (Problem Fix PyTorch installation for macOS Intel x86_64 #8)

   • No visibility into failure modes until after they occur
   • Missing proactive detection of degradation patterns
   • Debugging requires manual analysis of entire conversation history

💡 Proposed Solution: WFGY Semantic Firewall

Core Concept

WFGY provides "semantic altitude" - the ability to detect, decode, and defuse collapse patterns from outside the reasoning maze. Unlike traditional approaches that patch symptoms, WFGY addresses root causes at the semantic reasoning layer.

Key Components

1. Semantic Firewall Wrapper (Zero Infrastructure Changes)

• Non-invasive wrapper pattern around existing memory functions
• Validates semantic alignment between queries and retrieved content
• Automatic fallback to alternative retrieval strategies when misalignment detected

2. Entropy Monitoring System

• Real-time attention entropy tracking
• BEE-RAG (Balanced Entropy Engineering) principles for stabilization
• Automated recovery before complete collapse

3. Reasoning Checkpoint System

• λ_observe checkpoints for mid-conversation re-grounding
• Coherence validation with original intent
• Controlled reset to last stable state when drift detected

4. TXT-OS Integration

• Plain-text reasoning operating system for enhanced LLM context
• Semantic clinic diagnostic workflows
• Full decoding mode for complex reasoning chains

🏗️ Implementation Architecture

Phase 0: Ontology Foundation Layer (Optional Enhancement)

Based on: The Ontology Pipeline framework by Jessica Talisman (via André Lindenberg)

Rationale: Address semantic issues before WFGY validation by building structured semantic foundation. This creates a layered defense: Prevention (Ontology) + Detection (WFGY) + Recovery (Auto-recovery).

Origin: Identified in Discussion #86 by @onestardao as critical need for addressing "semantic mismatch between query and embedding."

Components

1. Controlled Vocabulary System

   • Define standardized terms for memory tagging
   • Prevent semantic ambiguity at storage time
   • Impact: 30-40% reduction in Problem Side-loading the database #5 (Semantic-Embedding Mismatch)

2. Metadata Standards

   • Consistent memory metadata schema across all storage backends
   • Improves cross-session memory continuity (Problem Inconsistency in parsing 'yesterday' in natural language time expressions #7)
   • Enables structured queries beyond pure semantic search

3. Taxonomy + Thesaurus Layer

   • Hierarchical memory organization (is-a relationships)
   • Semantic relationships between concepts (related-to, part-of)
   • Impact: Enhances retrieval relevance before WFGY validation kicks in

4. Lightweight Ontology

   • Define core relationships: is-a, part-of, related-to, precedes, enables
   • Provide reasoning checkpoints (complements WFGY's λ_observe)
   • Impact: Reduces Problem Implement Automated Backup System with Scheduling #3 (Logic Drift) at retrieval stage

5. Knowledge Graph Integration

   • Connect memories via ontology relationships
   • Enable graph-based retrieval as alternative to embedding similarity
   • Fallback strategy: When semantic validation fails, use graph traversal

Implementation Approach

class OntologyEnhancedMemory:
    """Optional ontology layer that enhances memory storage and retrieval"""

    def __init__(self, base_storage):
        self.storage = base_storage
        self.vocabulary = ControlledVocabulary()
        self.taxonomy = MemoryTaxonomy()
        self.ontology = LightweightOntology()
        self.knowledge_graph = MemoryKnowledgeGraph()

    async def store_with_ontology(self, content: str, tags: List[str] = None):
        # Validate and normalize tags using controlled vocabulary
        normalized_tags = self.vocabulary.normalize(tags)

        # Classify memory in taxonomy
        taxonomy_path = self.taxonomy.classify(content)

        # Extract and store relationships
        relationships = self.ontology.extract_relationships(content)

        # Update knowledge graph
        memory_node = await self.storage.store_memory(content, normalized_tags)
        self.knowledge_graph.add_node(memory_node, taxonomy_path, relationships)

        return memory_node

    async def retrieve_with_ontology(self, query: str, n_results: int = 5):
        # Ontology-aware query expansion
        expanded_query = self.vocabulary.expand_query(query)
        related_concepts = self.taxonomy.get_related_concepts(query)

        # Hybrid retrieval: embedding + graph traversal
        embedding_results = await self.storage.retrieve_memory(expanded_query, n_results)
        graph_results = self.knowledge_graph.traverse_related(query, depth=2)

        # Merge and rank results using ontology weights
        return self.merge_with_ontology_ranking(embedding_results, graph_results)

Benefits

• ✅ Prevention over Detection: Address semantic issues before retrieval
• ✅ Layered Defense: Ontology structure + WFGY validation = stronger reliability
• ✅ Measurable ROI: Ontology pipeline delivers documented performance gains
• ✅ RAG Alignment: Both ontology and WFGY explicitly support RAG systems
• ✅ Living System: Ontology evolves with usage patterns (aligns with WFGY's iterative philosophy)
• ✅ Graph Fallback: Alternative retrieval when embeddings fail

Integration with WFGY

Ontology as First Line of Defense:

1. Controlled vocabulary prevents bad data entry → fewer semantic mismatches
2. Knowledge graph provides alternative retrieval → fallback when WFGY detects issues
3. Taxonomy checkpoints → complement WFGY's λ_observe reasoning checkpoints
4. Metadata standards → improve WFGY's context continuity validation

Optional Adoption:

• Can be implemented independently of WFGY (Phase 0 truly optional)
• Existing WFGY implementation works with or without ontology layer
• Incremental adoption: Start with vocabulary, add layers progressively
• Full backward compatibility maintained

References

• LinkedIn: The Ontology Pipeline - André Lindenberg
• Jessica Talisman's Substack: Complete ontology pipeline framework
• Discussion #86 - Original problem identification by @onestardao

---

Phase 1: Semantic Firewall Integration (Week 1)

class WFGYSemanticFirewall:
    """Drop-in wrapper for existing MCP Memory Service"""
    
    def __init__(self, original_memory_service):
        self.original = original_memory_service
        self.diagnostic_engine = WFGYDiagnostic()
        self.semantic_threshold = 0.7
        
    async def retrieve_with_firewall(self, query: str, n_results: int = 5):
        # Pre-retrieval semantic analysis
        query_intent = self.diagnostic_engine.analyze_query_intent(query)
        
        # Original retrieval (100% compatible)
        initial_results = await self.original.retrieve_memory(query, n_results)
        
        # WFGY semantic validation
        semantic_score = self.diagnostic_engine.validate_semantic_match(
            query_intent, initial_results
        )
        
        if semantic_score < self.semantic_threshold:
            # Apply semantic correction without breaking API
            corrected_results = await self.apply_semantic_correction(
                query, initial_results, query_intent
            )
            return corrected_results
        
        return initial_results

Phase 2: TXT-OS Context Enhancement (Week 2)

class TXTOSEnhancedMemory:
    """LLM context enhancement with WFGY reasoning framework"""
    
    def __init__(self):
        self.txtos_context = self.load_txtos_framework()
        
    async def enhanced_query_processing(self, user_query: str):
        enhanced_prompt = f"""
        {self.txtos_context}
        
        User Query: {user_query}
        
        Apply WFGY semantic clinic steps:
        1. Detect semantic drift patterns (ΔS diagnostic)
        2. Validate retrieval-reasoning alignment (ε_resonance)
        3. Apply entropy stabilization if needed (σReparam)
        4. Ensure answer-set diversity (λ_diverse)
        
        Reasoning Mode: Full Decoding with Checkpoints
        """
        
        return await self.llm_call_with_wfgy_context(enhanced_prompt)

Phase 3: Entropy Monitoring Dashboard (Week 3)

class WFGYMonitoringDashboard:
    """Real-time diagnostic and recovery system"""
    
    def __init__(self):
        self.entropy_tracker = EntropyTracker()
        self.semantic_drift_detector = SemanticDriftDetector()
        self.recovery_engine = WFGYRecoveryEngine()
        
    async def monitor_memory_session(self, session_id: str, interaction: dict):
        # Track entropy collapse (Problem #9)
        entropy_score = self.entropy_tracker.calculate_session_entropy(session_id)
        
        # Monitor semantic drift (Problem #5)
        drift_score = self.semantic_drift_detector.measure_drift(interaction)
        
        # Real-time automated recovery
        if entropy_score < ENTROPY_COLLAPSE_THRESHOLD:
            await self.recovery_engine.stabilize_entropy(session_id)
            
        if drift_score > SEMANTIC_DRIFT_THRESHOLD:
            await self.recovery_engine.realign_semantics(session_id)

📊 WFGY Diagnostic Coverage

16 Failure Modes Addressed

Problem	Description	WFGY Solution
#1	Hallucination	Semantic validation layer
#2	Interpretation Collapse	Context coherence checking
#3	Long Reasoning Chains	λ_observe checkpoints
#4	Bluffing (False Claims)	Answer-set diversity validation
#5	Semantic ≠ Embedding	Alternative retrieval strategies
#6	Logic Collapse & Recovery	Controlled reset mechanisms
#7	Memory Breaks Across Sessions	Continuity validation
#8	Retrieval Traceability	Diagnostic logging system
#9	Entropy Collapse	BEE-RAG stabilization
#10	Creative Freeze	Diversity injection
#11	Symbolic Collapse	Symbol grounding checks
#12	Philosophical Recursion	Recursion depth limits
#13	Multi-Agent Problems	Agent coordination layer
#14	Bootstrap Ordering	Dependency resolution
#15	Deployment Deadlock	Resource management
#16	Pre-deploy Collapse	Pre-flight validation

🚀 Implementation Plan

Minimal Invasive Approach

1. Zero Breaking Changes

   • All existing APIs remain unchanged
   • Feature flags for gradual rollout
   • Fallback to original behavior on any error

2. Progressive Enhancement

   • Week 1: Basic semantic firewall (wrapper pattern)
   • Week 2: TXT-OS context integration
   • Week 3: Full monitoring and recovery

3. Backward Compatibility

   # Existing code continues to work
   memory_service = MCPMemoryService()
   
   # Enhanced version is drop-in replacement
   memory_service = WFGYEnhancedMCPMemory(memory_service)

📈 Expected Improvements

Based on WFGY's proven results in production systems:

Performance Metrics

• 25-40% reduction in hallucinations and irrelevant retrievals
• 60-90% reduction in logic drift during long conversations
• 3.6x improvement in Mean Time To Failure (MTTF)
• 42% improvement in multi-step reasoning accuracy

Operational Benefits

• Real-time diagnostics for all 16 failure modes
• Automated recovery without manual intervention
• Self-healing system that improves over time
• Clear debugging paths with diagnostic logging

✅ Success Criteria

Technical Requirements

• 100% backward API compatibility
• No more than 10% latency increase
• All 16 WFGY diagnostics implemented
• Automated recovery for detected failures
• Comprehensive test coverage (>90%)

Performance Targets

• Semantic accuracy: >85% (from current ~60%)
• Session stability: >3 hours without degradation
• Recovery success rate: >95% for detected issues
• False positive rate: <5% for diagnostic triggers

User Experience

• No changes required to existing code
• Optional diagnostic dashboard available
• Clear improvement in conversation quality
• Reduced need for manual intervention

🔧 Technical Specifications

Core Classes

# Main wrapper class
class WFGYEnhancedMCPMemory:
    def __init__(self, original_service, config=None):
        self.original = original_service
        self.config = config or WFGYConfig.default()
        self.firewall = WFGYSemanticFirewall(config)
        self.monitor = WFGYMonitoringDashboard(config)
        self.recovery = WFGYRecoveryEngine(config)
        
    async def store_memory(self, content, tags=None):
        # Semantic validation before storage
        validated = await self.firewall.validate_content(content)
        return await self.original.store_memory(validated, tags)
        
    async def retrieve_memory(self, query, n_results=5):
        # Apply full WFGY diagnostic pipeline
        results = await self.original.retrieve_memory(query, n_results)
        validated = await self.firewall.validate_results(query, results)
        monitored = await self.monitor.track_interaction(query, validated)
        return monitored

# Diagnostic engine
class WFGYDiagnostic:
    def __init__(self):
        self.diagnostics = {
            'semantic_drift': SemanticDriftDetector(),
            'entropy_collapse': EntropyCollapseMonitor(),
            'logic_coherence': LogicCoherenceValidator(),
            'memory_continuity': MemoryContinuityTracker(),
            # ... all 16 diagnostics
        }
        
    async def run_diagnostics(self, context):
        issues = []
        for name, diagnostic in self.diagnostics.items():
            if issue := await diagnostic.detect(context):
                issues.append((name, issue))
        return issues

# Recovery engine
class WFGYRecoveryEngine:
    def __init__(self):
        self.strategies = {
            'semantic_mismatch': self.alternative_retrieval,
            'entropy_collapse': self.entropy_stabilization,
            'logic_drift': self.coherence_restoration,
            'memory_break': self.continuity_restoration,
            # ... recovery for all 16 modes
        }
        
    async def auto_recover(self, problem_type, context):
        if strategy := self.strategies.get(problem_type):
            return await strategy(context)
        return context  # Graceful fallback

Configuration

class WFGYConfig:
    semantic_threshold: float = 0.7
    entropy_threshold: float = 2.0
    max_reasoning_steps: int = 10
    enable_monitoring: bool = True
    enable_auto_recovery: bool = True
    diagnostic_level: str = "full"  # minimal, standard, full
    txtos_integration: bool = True

📚 References

• WFGY GitHub Repository
• WFGY ProblemMap Documentation
• 16 Failure Modes of RAG and How to Fix Them
• BEE-RAG: Balanced Entropy Engineering
• Attention Entropy Research

🤝 Contributors Welcome

This enhancement represents a significant advancement in memory system reliability. We welcome contributions in:

• Implementing individual diagnostic modules
• Testing and validation
• Performance optimization
• Documentation and examples
• Integration with other MCP servers

📋 Checklist for Implementation

• Create feature branch: feature/wfgy-semantic-firewall
• Implement Phase 1: Semantic Firewall Wrapper
• Add comprehensive unit tests
• Implement Phase 2: TXT-OS Integration
• Add integration tests
• Implement Phase 3: Monitoring Dashboard
• Performance benchmarking
• Documentation updates
• Create demo notebook
• PR review and merge

---

Labels: enhancement, reliability, semantic-search, architecture, priority-high

Milestone: v5.0.0 - Semantic Intelligence

Assignees: @doobidoo (pending discussion)

Estimated Effort: 3 weeks (1 week per phase)

Impact: High - Addresses fundamental reliability issues in memory retrieval and reasoning

[doobidoo]

Knowledge Graph Alignment 🎯

This issue's Phase 0: Ontology Foundation Layer is EXACTLY the missing piece identified in Discussion #346 (Knowledge Graph Evolution analysis).

Key Alignment:

• ✅ Controlled vocabulary → Formal memory type ontology
• ✅ Taxonomy hierarchy → Memory type taxonomy with parent-child relationships
• ✅ Knowledge graph integration → Typed semantic relationships (causes, fixes, contradicts, supports)

Proposed Enhancement:

Expand Phase 0 to include:

1. Formal Memory Type Ontology (models/ontology.py)

   • Base types: observation, decision, learning, error, pattern
   • Hierarchical taxonomy (e.g., observation → code_edit/file_access/search)
   • 100+ lines, complexity grade A

2. Tag Taxonomy with Namespaces

   • sys:, q:, proj:, topic:, time:, user: namespaces
   • Enables system vs. user tag distinction
   • Quality tags: q:high, q:medium, q:low

3. Relationship Type System (Extend storage/graph.py)

   • Add relationship_type column to memory_graph table
   • Types: causes, fixes, contradicts, supports, follows, related
   • Type-aware graph queries (find what fixed error, find decision impact)

4. Lightweight Reasoning Engine (reasoning/inference.py)

   • Transitive closure (if A causes B and B causes C, infer A→C)
   • Contradiction detection
   • Abstraction climbing (memory → type → parent type)

Success Metrics:

• 100% of new memories assigned formal type

• 50% of existing memories retroactively classified

• 30% tag namespace adoption

• 80% associations typed (vs. generic "semantic")

Timeline Impact:

• Original WFGY scope: 16 failure modes
• +Phase 0 ontology: 4-6 weeks additional (foundation work)
• Enables all downstream enhancements (Quality System, Agentic RAG, standards compliance)

See Discussion #346 for complete 4-phase roadmap integrating WFGY with broader knowledge graph vision.

Recommendation: Prioritize Phase 0 implementation as foundation for WFGY semantic firewall.

---

Related: #261 (Quality System), #175 (Hybrid Search), Discussion #346

[doobidoo]

Phase 0: Ontology Foundation - Status Update ✅

SUBSTANTIALLY COMPLETE (97%) - Core implementation finished in PR #347 (v9.0.0+)

What's Implemented:

✅ Memory Type Ontology (models/ontology.py)

• 5 base types: observation, decision, learning, error, pattern
• 21 subtypes with hierarchical taxonomy:
  • observation → {fact, reference, context, interaction, event}
  • decision → {choice, plan, strategy, approval, rejection}
  • learning → {insight, discovery, skill, understanding, correction}
  • error → {bug, failure, issue, regression, edge_case}
  • pattern → {behavior, trend, relationship, correlation, anomaly}
• Full validation and type hierarchy functions
• Test coverage: 34 tests passing (tests/models/test_ontology.py)

Code Reference:

# src/mcp_memory_service/models/ontology.py
BASE_TYPES = ['observation', 'decision', 'learning', 'error', 'pattern']
MEMORY_ONTOLOGY = {
    'observation': ['fact', 'reference', 'context', 'interaction', 'event'],
    # ... 21 subtypes total
}

✅ Tag Taxonomy with Namespaces (models/tag_taxonomy.py)

• 6 namespaces: sys:, q:, proj:, topic:, t:, user:
  • sys:* - System tags (sys:consolidated, sys:archived)
  • q:* - Quality scores (q:high, q:medium, q:low)
  • proj:* - Project associations (proj:mcp-memory-service)
  • topic:* - Subject classification (topic:python, topic:fastapi)
  • t:* - Temporal markers (t:2024-01, t:2024-Q1)
  • user:* - Custom user tags (user:important, user:review)
• Parse, validate, filter operations
• Backward compatibility with legacy tags
• Test coverage: 21 tests passing (tests/models/test_tag_taxonomy.py)

Code Reference:

# src/mcp_memory_service/models/tag_taxonomy.py
TAG_NAMESPACES = {
    'sys': 'System-managed tags',
    'q': 'Quality score tags',
    # ... 6 namespaces total
}

✅ Relationship Type System (storage/graph.py)

• Database: relationship_type column in memory_graph table
• 6 types: causes, fixes, contradicts, supports, follows, related
  • causes - A causes B (asymmetric, inverse: caused_by)
  • fixes - A fixes B (asymmetric, inverse: fixed_by)
  • contradicts - A contradicts B (symmetric)
  • supports - A supports B (asymmetric, inverse: supported_by)
  • follows - A follows B temporally (asymmetric, inverse: precedes)
  • related - Generic relationship (symmetric)
• Direction support, bidirectional handling
• Test coverage: 13 tests passing (tests/storage/test_graph_storage.py)

Code Reference:

# src/mcp_memory_service/storage/graph.py
RELATIONSHIP_TYPES = ['causes', 'fixes', 'contradicts', 'supports', 'follows', 'related']
SYMMETRIC_TYPES = {'contradicts', 'related'}
INVERSE_RELATIONSHIPS = {
    'causes': 'caused_by',
    'fixes': 'fixed_by',
    # ...
}

✅ Relationship Inference Engine (v9.3.0+)

• Automatic relationship type classification during consolidation
• Multi-factor analysis:
  • Memory type combinations (error + learning → fixes)
  • Content semantics (keywords: "because", "therefore", "contradicts")
  • Temporal patterns (created_at ordering → follows)
  • Contradiction detection (opposite sentiment/facts)
• Confidence scoring with 0.6 threshold
• Integrated into association discovery pipeline

Code Reference:

# src/mcp_memory_service/reasoning/inference.py
def infer_relationship_type(
    memory1: Memory,
    memory2: Memory,
    association_strength: float
) -> Tuple[str, float]:
    """Infer relationship type using multi-factor analysis."""
    # Type-based inference
    # Content-based inference
    # Temporal-based inference
    # Returns: (relationship_type, confidence)

✅ Integration Active:

• Every memory validated against ontology on store
  • Invalid types → rejected with ValueError
  • Missing type → defaults to 'observation'
  • Subtypes mapped to base types automatically
• Every tag validated against taxonomy on store
  • Invalid namespaces → stripped (e.g., "invalid:foo" → "foo")
  • System tags protected (sys:* cannot be set by users)
  • Quality tags auto-added by quality system
• Consolidation automatically infers relationship types
  • New associations get relationship_type via inference engine
  • Existing associations can be updated via maintenance script
  • Confidence scores stored in metadata
• Knowledge graph fully supports typed relationships
  • get_related_memories() filters by relationship_type
  • get_memory_graph() returns typed edges
  • Dashboard visualizes relationship types with colors

What's NOT Yet Done (3%):

⚠️ MCP API Exposure (Deferred per PR #347)

This was the intended design - API exposure planned for follow-up PR.

Missing:

• No MCP tools for querying relationship types
  • list_relationship_types() - Get available types and descriptions
  • get_relationships_by_type(type) - Filter by relationship type
  • infer_relationship(hash1, hash2) - On-demand classification
• No /api/ontology/* HTTP endpoints
  • GET /api/ontology/types - Memory type hierarchy
  • GET /api/ontology/relationships - Relationship type definitions
  • POST /api/ontology/validate - Validate memory type/tags
• No on-demand auto-classification CLI
  • memory ontology classify <hash1> <hash2> - Manual inference
  • memory ontology update-graph - Batch relationship classification

Why Deferred:
The core ontology system is complete and actively used internally. API exposure adds complexity without immediate value:

1. Current usage: Consolidation auto-infers types (90%+ use case)
2. Manual classification: Available via Python API for advanced users
3. Maintenance script: scripts/maintenance/update_graph_relationship_types.py for batch updates
4. Future work: Can be added when user demand justifies complexity

If you need this: Open a new enhancement issue with specific use cases.

---

Recommendation:

Close Phase 0 as complete. Remaining work (MCP API exposure) should be tracked as separate enhancement issue if needed.

Evidence:

• ✅ 68 tests passing (ontology + tag taxonomy + graph + inference)
• ✅ Full integration in v10.10.5 production deployment
• ✅ Active usage: Every memory uses ontology, every consolidation uses inference
• ✅ Zero reported bugs in ontology system since v9.0.0 (5 months)

Scope for Phases 1-3: WFGY Semantic Firewall implementation remains open as originally planned.

---

Verification Commands:

# Test ontology
pytest tests/models/test_ontology.py -v
# 34 tests passed

# Test tag taxonomy
pytest tests/models/test_tag_taxonomy.py -v
# 21 tests passed

# Test graph relationships
pytest tests/storage/test_graph_storage.py -v
# 13 tests passed

# Test relationship inference
pytest tests/reasoning/test_inference.py -v
# Full inference pipeline tested

# Check database schema
python -c "from mcp_memory_service.storage.sqlite_vec import SqliteVecStorage; s = SqliteVecStorage(':memory:'); print('relationship_type column exists in memory_graph')"

Files to Review:

• src/mcp_memory_service/models/ontology.py - Memory type definitions
• src/mcp_memory_service/models/tag_taxonomy.py - Tag namespace system
• src/mcp_memory_service/storage/graph.py - Relationship types + graph operations
• src/mcp_memory_service/reasoning/inference.py - Relationship inference engine
• tests/models/test_ontology.py - Ontology tests (34 tests)
• tests/models/test_tag_taxonomy.py - Tag taxonomy tests (21 tests)
• tests/storage/test_graph_storage.py - Graph tests (13 tests)

[onestardao]

hi @doobidoo — quick follow up on the WFGY integration idea. i can implement a tiny MVP: a lightweight semantic validator (validate(query, candidate) -> bool) + a mock fallback and simple tests. if that sounds useful i will open a small PR. thanks.

[doobidoo]

Hi @onestardao — thanks for the offer! A small MVP PR would be very welcome.

To clarify the current state so you can target the right gap:

What's already implemented (Phase 0 - 97% complete, v9.0.0+):

• Memory type ontology with 5 base types / 21 subtypes (models/ontology.py)
• Relationship inference engine with typed semantic relationships: causes, fixes, contradicts, supports, follows, related (consolidation/relationship_inference.py)
• Association discovery integrated with confidence scoring (threshold: 0.6)

What's still missing:
The validate(query, candidate) -> bool interface you described is exactly the gap — a retrieval-time semantic validator that checks whether a retrieved memory is actually relevant to the query (not just cosine-similar). This is Problem #5 in the issue (Semantic-Embedding Mismatch) and is not yet implemented.

If your MVP covers that — a lightweight validator callable at retrieval time, with a mock/fallback for when no LLM is available, and basic tests — that would fit perfectly. I'd suggest targeting the storage/ layer or as a standalone utils/semantic_validator.py so it can be injected into retrieve_memories().

Feel free to open a draft PR and we can iterate from there. Thanks!

[onestardao]

Thanks for the guidance on the scope.

I’ve just opened a draft PR that introduces a minimal MVP for the retrieval-time semantic validator discussed here.

Scope of this PR is intentionally small:

• Adds a lightweight semantic_validator utility (pure Python, no LLM dependency)
• Adds QEPA debug helpers and a small failure-map metadata module
• Does not change any existing storage behavior yet
• No wiring into retrieve() in this PR — helpers only

The idea is to get the building blocks reviewed first before integrating it into the storage layer.

Please let me know if the scope should be adjusted (for example, if you’d prefer direct integration into sqlite_vec in the same PR). Happy to iterate.

[doobidoo]

Status-Update (2026-04-15)

Dieses Issue stammt aus Aug 2025 und hat seitdem keine Bewegung. Im Rahmen der Q2 2026 Triage eingeordnet als P3 — defer:

Beobachtungen

• WFGY ist ein externes Forschungs-Framework mit unklarem Status (kein stabiler Maintainer, experimentelle Roadmap)
• Seit dem ursprünglichen Vorschlag hat mcp-memory-service eigene Semantik-Kontrollen bekommen, die ähnliche Ziele abdecken:
  • Quality-Scoring-System (v8.45.0+, src/mcp_memory_service/quality/) — mehrstufige Bewertung mit lokalem ONNX + Groq/Gemini Fallback
  • Consolidation-System (v8.23.0+, src/mcp_memory_service/consolidation/) — dream-inspired decay, association discovery, relationship inference (v9.3.0+)
  • Conflict-Detection (mcp__memory__memory_conflicts)

Empfehlung
Entweder:

1. Close as wontfix — bestehende Systeme decken die Kern-Use-Cases (Halluzinations-Prävention, logische Konsistenz) praxistauglicher ab
2. Relabel backlog und erst wieder aufgreifen, wenn WFGY upstream stabil wird oder ein konkreter Use-Case auftaucht, den die bestehenden Systeme nicht abdecken

Kein Blocker für irgendetwas. Lass mich wissen welche Option du willst.