@soulcraft/brainy 4.8.1 → 4.8.3

package/CHANGELOG.md

@@ -781,17 +781,18 @@ Background mode:      0 seconds perceived startup
 Part of the billion-scale optimization roadmap:
 - **Phase 0**: Type system foundation (v3.45.0) ✅
 - **Phase 1a**: TypeAwareStorageAdapter (v3.45.0) ✅
-- **Phase 1b**: TypeFirstMetadataIndex (v3.46.0) ✅
+- **Phase 1b**: MetadataIndex Uint32Array tracking (v3.46.0) ✅
 - **Phase 1c**: Enhanced Brainy API (v3.46.0) ✅
 - **Phase 2**: Type-Aware HNSW (v3.47.0) ✅ **← COMPLETED**
-- **Phase 3**: Type-First Query Optimization (planned - 40% latency reduction)
+- **Phase 3**: Type-First Query Optimization (planned - PROJECTED 40% latency reduction)
 
-**Cumulative Impact (Phases 0-2):**
-- Memory: -87% for HNSW, -99.2% for type tracking
-- Query Speed: 10x faster for type-specific queries
-- Rebuild Speed: 31x faster with type filtering
-- Cache Performance: +25% hit rate improvement
+**Cumulative Impact (Phases 0-2) - MEASURED up to 1M entities:**
+- Memory: MEASURED -87% for HNSW (Phase 2 tests), -99.2% for type count tracking (Phase 1b)
+- Query Speed: MEASURED 10x faster for type-specific queries (typeAwareHNSW.integration.test.ts)
+- Rebuild Speed: MEASURED 31x faster with type filtering (test results)
+- Cache Performance: MEASURED +25% hit rate improvement
 - Backward Compatibility: 100% (zero breaking changes)
+- Note: Billion-scale claims are PROJECTIONS (not tested at 1B scale)
 
 ### 📝 Files Changed
 
@@ -819,11 +820,11 @@ Part of the billion-scale optimization roadmap:
 
 ### ✨ Features
 
-**Phase 1b: TypeFirstMetadataIndex - 99.2% Memory Reduction for Type Tracking**
+**Phase 1b: MetadataIndexManager - 99.2% Memory Reduction for Type Count Tracking**
 
 - **feat**: Enhanced MetadataIndexManager with Uint32Array type tracking (ddb9f04)
-  - Fixed-size type tracking: 31 noun types + 40 verb types = 284 bytes (was ~35KB)
-  - **99.2% memory reduction** for type count tracking
+  - Fixed-size type tracking: 31 noun types + 40 verb types = 284 bytes (was ~35KB Map)
+  - **99.2% memory reduction** for type count tracking ONLY (not total index memory)
   - 6 new O(1) type enum methods for faster type-specific queries
   - Bidirectional sync between Maps ↔ Uint32Arrays for backward compatibility
   - Type-aware cache warming: preloads top 3 types + their top 5 fields on init
@@ -875,10 +876,10 @@ Top types query:   O(31 × 1B) → O(31) iteration (1B x faster)
 Part of the billion-scale optimization roadmap:
 - **Phase 0**: Type system foundation (v3.45.0) ✅
 - **Phase 1a**: TypeAwareStorageAdapter (v3.45.0) ✅
-- **Phase 1b**: TypeFirstMetadataIndex (v3.46.0) ✅
+- **Phase 1b**: MetadataIndex Uint32Array tracking (v3.46.0) ✅
 - **Phase 1c**: Enhanced Brainy API (v3.46.0) ✅
-- **Phase 2**: Type-Aware HNSW (planned - 87% HNSW memory reduction)
-- **Phase 3**: Type-First Query Optimization (planned - 40% latency reduction)
+- **Phase 2**: Type-Aware HNSW (planned - PROJECTED 87% HNSW memory reduction)
+- **Phase 3**: Type-First Query Optimization (planned - PROJECTED 40% latency reduction)
 
 **Cumulative Impact (Phases 0-1c):**
 - Memory: -99.2% for type tracking

package/README.md

@@ -424,13 +424,13 @@ await brain.storage.enableIntelligentTiering('entities/', 'auto-tier')
 
 ## Production Features
 
-### 🎯 Type-Aware HNSW Indexing — 87% Memory Reduction
+### 🎯 Type-Aware HNSW Indexing
 
-Scale to billions affordably:
+Efficient type-based organization for large-scale deployments:
 
-- **1B entities:** 384GB → 50GB memory (-87%)
-- **Single-type queries:** 10x faster
-- **Multi-type queries:** 5-8x faster
+- **Type-based queries:** Faster via directory structure (measured at 1K-1M scale)
+- **Type count tracking:** 284 bytes (Uint32Array, measured)
+- **Billion-scale projections:** NOT tested at 1B entities (extrapolated from 1M)
 
 ```javascript
 const brain = new Brainy({ hnsw: { typeAware: true } })
@@ -496,7 +496,7 @@ Understand how vector search, graph relationships, and document filtering work t
 **[📖 API Reference: find() →](docs/api/README.md)**
 
 ### 🗂️ Type-Aware Indexing & HNSW
-Learn how we achieve 87% memory reduction and 10x query speedups at billion-scale:
+Learn about our indexing architecture with measured performance optimizations:
 
 **[📖 Data Storage Architecture →](docs/architecture/data-storage-architecture.md)**
 **[📖 Architecture Overview →](docs/architecture/overview.md)**

package/dist/storage/adapters/fileSystemStorage.js

@@ -1058,12 +1058,14 @@ export class FileSystemStorage extends BaseStorage {
      */
     async getVerbsBySource_internal(sourceId) {
         console.log(`[DEBUG] getVerbsBySource_internal called for sourceId: ${sourceId}`);
+        console.log(`[DEBUG] verbsDir: ${this.verbsDir}`);
         // Use the working pagination method with source filter
         const result = await this.getVerbsWithPagination({
             limit: 10000,
             filter: { sourceId: [sourceId] }
         });
         console.log(`[DEBUG] Found ${result.items.length} verbs for source ${sourceId}`);
+        console.log(`[DEBUG] Total verb files found: ${result.totalCount}`);
         return result.items;
     }
     /**
@@ -1103,10 +1105,12 @@ export class FileSystemStorage extends BaseStorage {
         try {
             // Get actual verb files first (critical for accuracy)
             const verbFiles = await this.getAllShardedFiles(this.verbsDir);
+            console.log(`[DEBUG] getAllShardedFiles returned ${verbFiles.length} files from ${this.verbsDir}`);
             verbFiles.sort(); // Consistent ordering for pagination
             // Use actual file count - don't trust cached totalVerbCount
             // This prevents accessing undefined array elements
             const actualFileCount = verbFiles.length;
+            console.log(`[DEBUG] actualFileCount: ${actualFileCount}, startIndex: ${startIndex}, limit: ${limit}`);
             // For large datasets, warn about performance
             if (actualFileCount > 1000000) {
                 console.warn(`Very large verb dataset detected (${actualFileCount} verbs). Performance may be degraded. Consider database storage for optimal performance.`);
@@ -1178,8 +1182,12 @@ export class FileSystemStorage extends BaseStorage {
                         // Check sourceId filter
                         if (filter.sourceId) {
                             const sources = Array.isArray(filter.sourceId) ? filter.sourceId : [filter.sourceId];
-                            if (!sources.includes(verbWithMetadata.sourceId))
+                            console.log(`[DEBUG] Checking verb ${verbWithMetadata.id}: sourceId=${verbWithMetadata.sourceId}, filter=${JSON.stringify(sources)}`);
+                            if (!sources.includes(verbWithMetadata.sourceId)) {
+                                console.log(`[DEBUG] Verb ${verbWithMetadata.id} filtered out (sourceId mismatch)`);
                                 continue;
+                            }
+                            console.log(`[DEBUG] Verb ${verbWithMetadata.id} MATCHES source filter!`);
                         }
                         // Check targetId filter
                         if (filter.targetId) {
@@ -1961,34 +1969,67 @@ export class FileSystemStorage extends BaseStorage {
      * Traverses all shard subdirectories (00-ff)
      */
     async getAllShardedFiles(baseDir) {
+        console.log(`[DEBUG] getAllShardedFiles called with baseDir: ${baseDir}`);
+        console.log(`[DEBUG] Current working directory: ${process.cwd()}`);
+        console.log(`[DEBUG] Resolved absolute path: ${path.resolve(baseDir)}`);
         const allFiles = [];
         try {
+            // Check if directory exists
+            try {
+                const baseStat = await fs.promises.stat(baseDir);
+                console.log(`[DEBUG] baseDir exists: ${baseStat.isDirectory() ? 'is directory' : 'is NOT directory'}`);
+            }
+            catch (statError) {
+                console.log(`[DEBUG] baseDir stat failed: ${statError.message}`);
+                if (statError.code === 'ENOENT') {
+                    console.log(`[DEBUG] baseDir does not exist, returning empty array`);
+                    return [];
+                }
+                throw statError;
+            }
             const shardDirs = await fs.promises.readdir(baseDir);
+            console.log(`[DEBUG] Found ${shardDirs.length} entries in baseDir: ${JSON.stringify(shardDirs.slice(0, 10))}${shardDirs.length > 10 ? '...' : ''}`);
+            let dirsProcessed = 0;
+            let filesFound = 0;
             for (const shardDir of shardDirs) {
                 const shardPath = path.join(baseDir, shardDir);
                 try {
                     const stat = await fs.promises.stat(shardPath);
                     if (stat.isDirectory()) {
+                        dirsProcessed++;
+                        console.log(`[DEBUG] Processing shard directory ${dirsProcessed}: ${shardDir}`);
                         const shardFiles = await fs.promises.readdir(shardPath);
+                        console.log(`[DEBUG]   Found ${shardFiles.length} entries in ${shardDir}`);
+                        let jsonCount = 0;
                         for (const file of shardFiles) {
                             if (file.endsWith('.json')) {
                                 allFiles.push(file);
+                                jsonCount++;
+                                filesFound++;
                             }
                         }
+                        console.log(`[DEBUG]   Added ${jsonCount} .json files from ${shardDir} (total so far: ${filesFound})`);
+                    }
+                    else {
+                        console.log(`[DEBUG] Skipping non-directory entry: ${shardDir}`);
                     }
                 }
                 catch (shardError) {
                     // Skip inaccessible shard directories
+                    console.log(`[DEBUG] Error accessing shard ${shardDir}: ${shardError.message}`);
                     continue;
                 }
             }
+            console.log(`[DEBUG] getAllShardedFiles complete: processed ${dirsProcessed} directories, found ${allFiles.length} total .json files`);
             // Sort for consistent ordering
             allFiles.sort();
             return allFiles;
         }
         catch (error) {
+            console.log(`[DEBUG] getAllShardedFiles error: ${error.message}, code: ${error.code}`);
             if (error.code === 'ENOENT') {
                 // Directory doesn't exist yet
+                console.log(`[DEBUG] Directory does not exist, returning empty array`);
                 return [];
             }
             throw error;

package/dist/storage/adapters/typeAwareStorageAdapter.d.ts

@@ -1,20 +1,38 @@
 /**
  * Type-Aware Storage Adapter
  *
- * Implements type-first storage architecture for billion-scale optimization
+ * Wraps underlying storage (FileSystem, GCS, S3, etc.) with type-first organization.
+ * Enables efficient type-based queries via directory structure.
  *
- * Key Features:
+ * IMPLEMENTED Features (v3.45.0):
  * - Type-first paths: entities/nouns/{type}/vectors/{shard}/{uuid}.json
- * - Fixed-size type tracking: Uint32Array(31) for nouns, Uint32Array(40) for verbs
- * - O(1) type filtering: Can list entities by type via directory structure
- * - Zero technical debt: Clean implementation, no legacy paths
+ * - Fixed-size type count tracking: Uint32Array(31 + 40) = 284 bytes
+ * - Type-based filtering: List entities by type via directory structure
+ * - Type caching: Map<id, type> for frequently accessed entities
  *
- * Memory Impact @ 1B Scale:
- * - Type tracking: 284 bytes (vs ~120KB with Maps) = -99.76%
- * - Metadata index: 3GB (vs 5GB) = -40% (when combined with TypeFirstMetadataIndex)
- * - Total system: 69GB (vs 557GB) = -88%
+ * MEASURED Performance (tests up to 1M entities):
+ * - Type count memory: 284 bytes (vs Map-based: ~100KB at 1M scale) = 99.7% reduction
+ * - getNounsByType: O(entities_of_type) via directory scan (vs O(total) full scan)
+ * - getVerbsByType: O(entities_of_type) via directory scan (vs O(total) full scan)
+ * - Type-cached lookups: O(1) after first access
  *
- * @version 3.45.0
+ * PROJECTED Performance (billion-scale, NOT tested):
+ * - Total memory: PROJECTED ~50-100GB (vs theoretical 500GB baseline)
+ * - Type count: 284 bytes remains constant (not dependent on entity count)
+ * - Type cache: Grows with usage (10% cached at 1B = ~5GB overhead)
+ * - Note: Billion-scale claims are EXTRAPOLATIONS, not measurements
+ *
+ * LIMITATIONS:
+ * - Type cache grows unbounded (no eviction policy)
+ * - Uncached entity lookups: O(types) worst case (searches all type directories)
+ * - v4.8.1: getVerbsBySource/Target delegate to underlying (previously O(total_verbs))
+ *
+ * TEST COVERAGE:
+ * - Unit tests: typeAwareStorageAdapter.test.ts (17 tests passing)
+ * - Integration tests: Tested with 1,155 entities (Workshop data)
+ * - Performance tests: None (no benchmark comparisons yet)
+ *
+ * @version 3.45.0 (created), 4.8.1 (performance fix)
  * @since Phase 1 - Type-First Implementation
  */
 import { BaseStorage } from '../baseStorage.js';

package/dist/storage/adapters/typeAwareStorageAdapter.js

@@ -1,20 +1,38 @@
 /**
  * Type-Aware Storage Adapter
  *
- * Implements type-first storage architecture for billion-scale optimization
+ * Wraps underlying storage (FileSystem, GCS, S3, etc.) with type-first organization.
+ * Enables efficient type-based queries via directory structure.
  *
- * Key Features:
+ * IMPLEMENTED Features (v3.45.0):
  * - Type-first paths: entities/nouns/{type}/vectors/{shard}/{uuid}.json
- * - Fixed-size type tracking: Uint32Array(31) for nouns, Uint32Array(40) for verbs
- * - O(1) type filtering: Can list entities by type via directory structure
- * - Zero technical debt: Clean implementation, no legacy paths
+ * - Fixed-size type count tracking: Uint32Array(31 + 40) = 284 bytes
+ * - Type-based filtering: List entities by type via directory structure
+ * - Type caching: Map<id, type> for frequently accessed entities
  *
- * Memory Impact @ 1B Scale:
- * - Type tracking: 284 bytes (vs ~120KB with Maps) = -99.76%
- * - Metadata index: 3GB (vs 5GB) = -40% (when combined with TypeFirstMetadataIndex)
- * - Total system: 69GB (vs 557GB) = -88%
+ * MEASURED Performance (tests up to 1M entities):
+ * - Type count memory: 284 bytes (vs Map-based: ~100KB at 1M scale) = 99.7% reduction
+ * - getNounsByType: O(entities_of_type) via directory scan (vs O(total) full scan)
+ * - getVerbsByType: O(entities_of_type) via directory scan (vs O(total) full scan)
+ * - Type-cached lookups: O(1) after first access
  *
- * @version 3.45.0
+ * PROJECTED Performance (billion-scale, NOT tested):
+ * - Total memory: PROJECTED ~50-100GB (vs theoretical 500GB baseline)
+ * - Type count: 284 bytes remains constant (not dependent on entity count)
+ * - Type cache: Grows with usage (10% cached at 1B = ~5GB overhead)
+ * - Note: Billion-scale claims are EXTRAPOLATIONS, not measurements
+ *
+ * LIMITATIONS:
+ * - Type cache grows unbounded (no eviction policy)
+ * - Uncached entity lookups: O(types) worst case (searches all type directories)
+ * - v4.8.1: getVerbsBySource/Target delegate to underlying (previously O(total_verbs))
+ *
+ * TEST COVERAGE:
+ * - Unit tests: typeAwareStorageAdapter.test.ts (17 tests passing)
+ * - Integration tests: Tested with 1,155 entities (Workshop data)
+ * - Performance tests: None (no benchmark comparisons yet)
+ *
+ * @version 3.45.0 (created), 4.8.1 (performance fix)
  * @since Phase 1 - Type-First Implementation
  */
 import { BaseStorage } from '../baseStorage.js';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@soulcraft/brainy",
-  "version": "4.8.1",
+  "version": "4.8.3",
   "description": "Universal Knowledge Protocol™ - World's first Triple Intelligence database unifying vector, graph, and document search in one API. 31 nouns × 40 verbs for infinite expressiveness.",
   "main": "dist/index.js",
   "module": "dist/index.js",