.aiignore

@@ -0,0 +1,12 @@
+# An .aiignore file follows the same syntax as a .gitignore file.
+# .gitignore documentation: https://git-scm.com/docs/gitignore
+
+# you can ignore files
+.DS_Store
+*.log
+*.tmp
+
+# or folders
+dist/
+build/
+out/

.claude/skills/architecture.md

@@ -0,0 +1,170 @@
+# Brainy Architecture Reference
+
+## What Is Brainy
+
+@soulcraft/brainy (v7.17.0) is a Universal Knowledge Protocol -- a Triple Intelligence database combining vector search, graph traversal, and metadata filtering in a single library. Published to npm as a public MIT-licensed package.
+
+## Core Architecture
+
+### Storage Layer (`src/storage/`)
+- **StorageAdapter interface** (`src/coreTypes.ts:576`): The contract ALL storage backends implement. ALWAYS check this interface before adding storage methods.
+- **BaseStorage** (`src/storage/baseStorage.ts`): Base implementation with built-in type-aware partitioning (TypeAwareStorageAdapter was removed -- functionality merged into BaseStorage).
+- **Adapters** (`src/storage/adapters/`):
+  - `fileSystemStorage.ts` -- local filesystem
+  - `memoryStorage.ts` -- in-memory
+  - `baseStorageAdapter.ts` -- shared adapter base (counts, batch ops)
+  - Cloud + OPFS adapters were removed in 8.0 (cloud backup is operator tooling)
+- **Generational MVCC / Db API** (`src/db/`): immutable `Db` values over generation-stamped records
+  - `db.ts` (the `Db` value), `generationStore.ts` (record layer + commit protocol), `types.ts`, `errors.ts`, `whereMatcher.ts`
+  - Design record: `docs/ADR-001-generational-mvcc.md`; replaced the pre-8.0 COW branching + versioning subsystems
+
+### Vector Search (`src/hnsw/`)
+- `hnswIndex.ts` -- HNSW-based approximate nearest neighbor search
+- `typeAwareHNSWIndex.ts` -- type-partitioned vector search
+- NOT in `src/intelligence/` (that directory does not exist)
+
+### Graph Engine (`src/graph/`)
+- `graphAdjacencyIndex.ts` -- adjacency-based graph representation
+- `pathfinding.ts` -- relationship traversal and pathfinding
+- `lsm/` -- LSM tree implementation for graph storage
+
+### Metadata Index (`src/utils/metadataIndex.ts`)
+- O(1) exact match via hash indexes
+- O(log n) range queries via sorted indexes
+- Roaring bitmap set operations for efficient filtering
+- Adaptive chunking strategy (`metadataIndexChunking.ts`)
+- Caching layer (`metadataIndexCache.ts`)
+
+### Triple Intelligence (`src/triple/`)
+- `TripleIntelligenceSystem.ts` -- combines vector + graph + metadata into unified queries
+- Lazy-loaded indexes (loaded on first use, not at startup)
+
+### Neural/AI Components (`src/neural/`)
+- Smart Importers (`src/importers/`): CSV, Excel, PDF, DOCX, YAML, JSON, Markdown, Orchestrator
+- `SmartExtractor.ts` -- entity extraction from unstructured data
+- `SmartRelationshipExtractor.ts` -- relationship detection
+- `NeuralEntityExtractor.ts` -- ML-based entity recognition
+- Natural language processing utilities
+
+### Distributed Systems (`src/distributed/`)
+- Distributed Coordinator for multi-node operation
+- Shard Manager for data partitioning
+- Cache Synchronization across nodes
+- Read/Write separation
+- Network and HTTP transport layers
+- Storage discovery and shard migration
+
+### Transaction Management (`src/transaction/`)
+- TransactionManager for ACID operations
+- Operations: SaveNoun, AddToHNSW, UpdateMetadata, etc.
+- Distributed transaction support
+
+### Integration Hub (`src/integrations/`)
+- Google Sheets integration
+- OData (Open Data Protocol)
+- Server-Sent Events (SSE)
+- Webhooks
+- Event bus system
+
+### Virtual Filesystem (`src/vfs/`)
+- `VirtualFileSystem.ts` -- full VFS implementation (87 KB)
+- `PathResolver.ts`, `FSCompat.ts`, `MimeTypeDetector.ts`, `TreeUtils.ts`
+- Subdirectories: `semantic/` (semantic search), `streams/` (streaming), `importers/`
+
+### MCP Support (`src/mcp/`)
+- BrainyMCPAdapter, MCPAugmentationToolset, BrainyMCPService
+- Model Control Protocol request/response handling
+
+### Aggregation Engine (`src/aggregation/`)
+- **AggregationIndex** (`AggregationIndex.ts`): Write-time incremental aggregation — SUM, COUNT, AVG, MIN, MAX with GROUP BY and time windows
+- **Time Windows** (`timeWindows.ts`): ISO 8601 bucketing — hour, day, week, month, quarter, year, custom intervals
+- **Materializer** (`materializer.ts`): Debounced writes of aggregate results as `NounType.Measurement` entities
+- Integrates into `brain.find({ aggregate })` for unified query API
+- Write hooks in `add()`, `update()`, `delete()` for O(1) incremental updates
+- `'aggregation'` provider key enables native plugin acceleration
+
+### Additional Systems
+- **CLI** (`src/cli/`): Complete command-line tool with interactive mode and catalog system
+- **Migration** (`src/migration/`): MigrationRunner for database schema migrations
+- **Embeddings** (`src/embeddings/`): Embedding manager with Candle-WASM Rust source
+- **Streaming** (`src/streaming/`): Pipeline support with adaptive backpressure
+- **Versioning** (`src/versioning/`): VersioningAPI for data versioning
+- **Plugin System**: Registry-based plugin architecture
+- **Patterns** (`src/patterns/`): 7 pattern library JSON files
+
+## Type System
+- **NounType** (42 types, `src/types/graphTypes.ts:850-893`): Person, Organization, Concept, Collection, Document, Task, Project, etc.
+- **VerbType** (127 types, `src/types/graphTypes.ts:900-1087`): Contains, RelatedTo, PartOf, Creates, DependsOn, MemberOf, etc.
+- All types in `src/types/`
+
+## Module Exports (`src/index.ts`)
+38+ named exports including: Brainy class, configuration types, neural APIs (NeuralImport, NeuralEntityExtractor, SmartExtractor, SmartRelationshipExtractor), distance functions, plugin system, migration system, embedding functions, storage adapters, COW infrastructure, pipeline utilities, graph types, MCP components, integration hub, OData utilities, and more.
+
+## File Structure
+```
+src/
+├── index.ts              # 38+ public exports
+├── brainy.ts             # Main Brainy class (6,500+ lines)
+├── setup.ts              # Initialization polyfills
+├── coreTypes.ts          # StorageAdapter interface + core types
+├── storage/
+│   ├── baseStorage.ts    # Base storage (includes type-aware)
+│   ├── adapters/         # All storage backends + cloud adapters
+│   └── cow/              # Copy-on-Write versioning
+├── hnsw/                 # HNSW vector search
+├── graph/                # Graph engine + pathfinding + LSM
+├── triple/               # Triple Intelligence system
+├── neural/               # Smart extractors + NLP
+├── importers/            # File format importers (8 types)
+├── distributed/          # Distributed database (16 files)
+├── transaction/          # ACID transactions (6 files)
+├── integrations/         # Sheets, OData, SSE, Webhooks
+├── vfs/                  # Virtual filesystem + semantic search
+├── mcp/                  # Model Control Protocol
+├── cli/                  # Command-line interface
+├── migration/            # Schema migrations
+├── embeddings/           # Embedding manager + Candle-WASM
+├── streaming/            # Pipeline + backpressure
+├── versioning/           # Versioning API
+├── types/                # TypeScript type definitions
+├── utils/                # Metadata index, logging, etc.
+├── config/               # Configuration system
+├── patterns/             # Pattern library
+├── api/                  # API layer
+├── interfaces/           # Interface definitions
+├── shared/               # Shared utilities
+├── data/                 # Data utilities
+├── errors/               # Error handling
+├── critical/             # Critical error handling
+├── universal/            # Universal utilities
+├── import/               # Import functionality
+└── scripts/              # Build scripts
+```
+
+## Initialization
+`brainy.ts` `init()` method performs initialization cascade:
+1. Load plugins
+2. Initialize storage
+3. Enable COW (Copy-on-Write)
+4. Set up embeddings
+5. Initialize caches
+6. Set up graph indexes
+7. Initialize VFS
+8. Set up transaction manager
+9. Initialize distributed components (if enabled)
+
+## Testing
+- Framework: Vitest
+- Run: `npm test`
+- Test directories:
+  - `tests/unit/` -- unit tests
+  - `tests/integration/` -- integration tests
+  - `tests/benchmarks/` -- performance benchmarks (NOT tests/performance/)
+  - `tests/comprehensive/` -- comprehensive test suites
+  - `tests/api/` -- API tests
+  - `tests/helpers/` -- test utilities
+
+## Release
+- `npm run release:patch/minor/major` -- fully automated via `scripts/release.sh`
+- `npm run release:dry` -- preview without changes
+- Uses conventional commits for changelog generation

.dockerignore

@@ -0,0 +1,57 @@
+# Git
+.git
+.gitignore
+
+# Development
+.vscode
+.idea
+*.swp
+*.swo
+.DS_Store
+
+# Node
+node_modules
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+# Testing
+tests
+*.test.ts
+*.test.js
+coverage
+.nyc_output
+
+# Documentation (keep only essentials)
+docs
+*.md
+!README.md
+!LICENSE
+
+# Build artifacts (will be built in Docker)
+dist
+build
+*.tsbuildinfo
+
+# Environment
+.env
+.env.*
+
+# Strategy and private docs
+.strategy
+CLAUDE.md
+
+# Development files
+docker-compose.yml
+Dockerfile
+.dockerignore
+
+# Data (should be mounted, not baked in)
+data
+*.db
+*.sqlite
+
+# Models (should be downloaded at runtime or mounted)
+models
+*.onnx
+*.bin

.forgejo/workflows/ci.yml

@@ -0,0 +1,40 @@
+name: CI
+
+on:
+  push:
+  pull_request:
+
+jobs:
+  node:
+    name: Node ${{ matrix.node-version }}
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        node-version: ['22', '24']
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: ${{ matrix.node-version }}
+          cache: npm
+      - run: npm ci
+      - run: npm run test:unit
+
+  bun:
+    name: Bun (latest)
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '22'
+          cache: npm
+      - uses: oven-sh/setup-bun@v2
+        with:
+          bun-version: latest
+      - run: npm ci
+      # test:bun imports the built dist/, so build first.
+      - run: npm run build
+      # Bun as a runtime is the supported Bun story (`bun add` / `bun run`).
+      - run: npm run test:bun

.github/FUNDING.yml

@@ -1,15 +0,0 @@
-# These are supported funding model platforms
-
-github: DPSIFR
-patreon: # Replace with a single Patreon username
-open_collective: # Replace with a single Open Collective username
-ko_fi: # Replace with a single Ko-fi username
-tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
-community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
-liberapay: # Replace with a single Liberapay username
-issuehunt: # Replace with a single IssueHunt username
-lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
-polar: # Replace with a single Polar username
-buy_me_a_coffee: # Replace with a single Buy Me a Coffee username
-thanks_dev: # Replace with a single thanks.dev username
-custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,32 +0,0 @@
----
-name: Bug report
-about: Create a report to help us improve
-title: '[BUG] '
-labels: bug
-assignees: ''
----
-
-## Bug Description
-A clear and concise description of what the bug is.
-
-## Reproduction Steps
-Steps to reproduce the behavior:
-1. Initialize BrainyData with '...'
-2. Call method '....'
-3. See error
-
-## Expected Behavior
-A clear and concise description of what you expected to happen.
-
-## Environment
-- Brainy version: [e.g. 0.9.4]
-- Environment: [e.g. Browser, Node.js, serverless]
-- Browser (if applicable): [e.g. Chrome, Safari]
-- Node.js version (if applicable): [e.g. 23.11.0]
-- Operating System: [e.g. Windows 10, macOS Monterey, Ubuntu 22.04]
-
-## Additional Context
-Add any other context about the problem here. If applicable, include code snippets, error messages, or screenshots.
-
-## Possible Solution
-If you have suggestions on how to fix the issue, please describe them here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,22 +0,0 @@
----
-name: Feature request
-about: Suggest an idea for this project
-title: '[FEATURE] '
-labels: enhancement
-assignees: ''
----
-
-## Problem Statement
-A clear and concise description of what problem this feature would solve. For example: "I'm always frustrated when [...]"
-
-## Proposed Solution
-A clear and concise description of what you want to happen.
-
-## Alternative Solutions
-A clear and concise description of any alternative solutions or features you've considered.
-
-## Use Case
-Describe a concrete use case that highlights the value of this feature.
-
-## Additional Context
-Add any other context, code examples, or references about the feature request here.

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,27 +0,0 @@
-## Description
-Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context.
-
-Fixes # (issue)
-
-## Type of change
-Please delete options that are not relevant.
-
-- [ ] Bug fix (non-breaking change which fixes an issue)
-- [ ] New feature (non-breaking change which adds functionality)
-- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
-- [ ] Documentation update
-- [ ] Performance improvement
-- [ ] Code refactoring (no functional changes)
-
-## How Has This Been Tested?
-Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce.
-
-## Checklist:
-- [ ] My code follows the style guidelines of this project
-- [ ] I have performed a self-review of my own code
-- [ ] I have commented my code, particularly in hard-to-understand areas
-- [ ] I have made corresponding changes to the documentation
-- [ ] My changes generate no new warnings
-- [ ] I have added tests that prove my fix is effective or that my feature works
-- [ ] New and existing unit tests pass locally with my changes
-- [ ] Any dependent changes have been merged and published in downstream modules

.github/workflows/deploy-demo.yml

@@ -1,68 +0,0 @@
-name: Deploy Demo to GitHub Pages
-
-on:
-  push:
-    branches: [ main ]
-  workflow_dispatch:
-
-# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
-permissions:
-  contents: read
-  pages: write
-  id-token: write
-
-# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
-# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
-concurrency:
-  group: "pages"
-  cancel-in-progress: false
-
-jobs:
-  build:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout 🛎️
-        uses: actions/checkout@v4
-
-      - name: Setup Node.js 🔧
-        uses: actions/setup-node@v3
-        with:
-          node-version: '20'
-          cache: 'npm'
-
-      - name: Install dependencies 📦
-        run: npm install --legacy-peer-deps
-
-      - name: Build project 🏗️
-        run: |
-          npm run build
-          npm run build:browser
-
-      - name: Prepare deployment 📦
-        run: |
-          mkdir -p _site
-          mkdir -p _site/demo
-          mkdir -p _site/dist
-          cp index.html _site/
-          cp demo/index.html _site/demo/
-          cp -r dist/* _site/dist/
-          cp brainy.png _site/
-          # Copy dist directly to demo/dist for easier access
-          mkdir -p _site/demo/dist
-          cp -r dist/* _site/demo/dist/
-
-      - name: Upload artifact
-        uses: actions/upload-pages-artifact@v3
-        with:
-          path: _site
-
-  deploy:
-    environment:
-      name: github-pages
-      url: ${{ steps.deployment.outputs.page_url }}
-    runs-on: ubuntu-latest
-    needs: build
-    steps:
-      - name: Deploy to GitHub Pages
-        id: deployment
-        uses: actions/deploy-pages@v4

.gitignore

@@ -1,75 +1,116 @@
-# Build output
-/tmp
-/out-tsc
-/dist
-/cloud-wrapper/dist
-
 # Dependencies
-/node_modules
-/cloud-wrapper/node_modules
+node_modules/
 npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
-/.pnp
-.pnp.js
 
-# Coverage directory
-/coverage
+# Build outputs
+dist/
+build/
+*.tsbuildinfo
 
-# Environment files
+# Environment variables
 .env
 .env.local
 .env.development.local
 .env.test.local
 .env.production.local
 
+# Runtime data
+brainy-data/
+.brainy/
+*.log
+*.pid
+*.seed
+*.pid.lock
+
+# Coverage directory used by tools like istanbul
+coverage/
+*.lcov
+
+# Test results
+tests/results/
+
+# Filesystem test artifacts (created by integration tests)
+test-*/
+
 # IDE files
 .vscode/
 .idea/
-*.iml
-*.iws
-*.ipr
-*.sublime-workspace
-*.sublime-project
+*.swp
+*.swo
+*~
 
 # OS files
 .DS_Store
 Thumbs.db
 
-# Data directories created by FileSystemStorage
-/brainy-data
-/custom-data
-/clean-history.sh
-/bluesky-augmentation/node_modules/
-/bluesky-augmentation/dist/
+# Temporary files
+tmp/
+temp/
+*.tmp
 
-# Test files
-/test-worker.js
-/test-node24-worker.js
-/test-results.json
-/tests/results/
-/tests/results/*.json
+# Planning and instruction files
+plan.md
 
-# Generated files
-/encoded-image.html
-/encoded-image.txt
-/cli-package/dist/
-/cli-package/node_modules/
-/npm
-/rollup
-/soulcraft-brainy-*.tgz
-/data/
-/cli-package/soulcraft-brainy-cli-*.tgz
-/web-service-package/node_modules/
+# Package files
+*.tgz
 
-# Temporary test files created by AI agents
-test*.js
-test*.ts
-temp-test*.js
-temp-test*.ts
-reproduction*.js
-reproduction*.ts
-debug*.js
-debug*.ts
-/temp/
-/temp-tests/
+# Private/confidential files
+PLAN.md
+INTERNAL_NOTES.md
+TODO_PRIVATE.md
+*.tar.gz
+
+# Strategy and planning documents (private)
+.strategy/
+# Removed: PRODUCTION_*.md (now these should be public documentation)
+DISTRIBUTED_*.md
+*_ASSESSMENT.md
+*_ANALYSIS.md
+*_TRUTH*.md
+
+# Models (downloaded at runtime)
+models/
+models-cache/
+
+# But include bundled WASM model assets
+!assets/models/
+
+# Development planning files (not for commit)
+PLAN.md
+
+# Backup folders
+backup-*
+backup/
+
+# Internal documentation
+docs/internal/
+
+# Cache files
+*.cache
+
+# Rust/Cargo build artifacts
+src/embeddings/candle-wasm/target/
+src/embeddings/candle-wasm/Cargo.lock
+
+# Ignore the wasm-pack output dir's CONTENTS (note the `/*`, not `/`, so the
+# re-includes below can take effect — git cannot re-include a file whose parent
+# DIRECTORY is excluded). Keep the pre-built WASM committed: it ships in the npm
+# package anyway, it lets consumers + CI build without a Rust/wasm-pack toolchain,
+# and versioning it makes the shipped artifact reproducible (not "whatever the
+# maintainer last built").
+src/embeddings/wasm/pkg/*
+!src/embeddings/wasm/pkg/*.wasm
+!src/embeddings/wasm/pkg/*.js
+!src/embeddings/wasm/pkg/*.d.ts
+
+# Log files (redundant but explicit)
+*.log
+
+# Temporary files (redundant but explicit)
+*.tmp
+/.junie/guidelines.md
+
+# Claude Code harness state
+.claude/scheduled_tasks.lock

.npmignore

@@ -1,41 +1,84 @@
-# Exclude source maps
-*.map
-**/*.map
-
-# Development files
-node_modules/
+# Source files (not needed in package)
 src/
 tests/
-examples/
-.github/
-.vscode/
-.idea/
-cloud-wrapper/
 scripts/
+coverage/
+
+# Model files (downloaded on first use, not bundled)
+models/
+models-cache/
+
+# Development and backup files
+backup-*
+backup-*/
+docs/backup*/
+
+# Documentation (except essentials)
+*.md
+!README.md
+!LICENSE
+!CHANGELOG.md
+!MIGRATION.md
 
 # Configuration files
-.eslintrc
-.prettierrc
-tsconfig*.json
-rollup.config.js
-jest.config.js
+.gitignore
+.npmignore
+tsconfig.json
+vitest.config.ts
+vitest.config.mts
+*.config.js
+*.config.ts
+.eslintrc*
+.prettierrc*
 
-# Build artifacts
-emocoverage/
-.nyc_output/
+# Test files
+test-*.js
+test-*.ts
+*.test.ts
+*.test.js
+*.spec.ts
+*.spec.js
 
-# Large files
-# Include the logo but exclude other PNGs
-!brainy.png
-*.png
-encoded-image.*
-README.demo.md
-scalingStrategy.md
-
-# Misc
-.DS_Store
+# Temporary and log files
 *.log
-npm-debug.log*
-yarn-debug.log*
-yarn-error.log*
-test-results.json
+*.tmp
+tmp/
+temp/
+brainy-data/
+
+# Git and CI files
+.git/
+.github/
+.gitlab-ci.yml
+.travis.yml
+
+# IDE files
+.vscode/
+.idea/
+*.swp
+*.swo
+
+# OS files
+.DS_Store
+Thumbs.db
+
+# Private files
+PLAN.md
+CLAUDE.md
+INTERNAL_NOTES.md
+TODO_PRIVATE.md
+*-ANALYSIS.md
+*-PLAN.md
+
+# Build artifacts not needed
+*.tsbuildinfo
+*.map
+
+# Development environment
+.env*
+.nvm*
+.node-version
+
+# Keep dist/ for the compiled code
+# Keep bin/ for the CLI
+# Keep package.json, package-lock.json

.nvmrc

@@ -0,0 +1 @@
+22

CHANGES.md

@@ -1,127 +0,0 @@
-# Brainy Changelog and Implementation Summaries
-
-<div align="center">
-<img src="./brainy.png" alt="Brainy Logo" width="200"/>
-</div>
-
-This document provides a comprehensive record of changes and implementation summaries for the Brainy project.
-
-## Table of Contents
-
-- [Recent Changes](#recent-changes)
-- [Statistics Optimizations Implementation](#statistics-optimizations-implementation)
-
-## Recent Changes
-
-### 2025-07-28
-
-#### Bug Fixes
-
-- Fixed an issue in FileSystemStorage constructor where path operations were performed before the path module was fully loaded. The fix defers path operations until the init() method is called, when the path module is guaranteed to be loaded.
-
-#### Details
-
-The issue was in the FileSystemStorage constructor where it was using the path module synchronously:
-
-```typescript
-constructor(rootDirectory: string) {
-  super()
-  this.rootDir = rootDirectory
-  this.nounsDir = path.join(this.rootDir, NOUNS_DIR)  // Error here - path could be undefined
-  this.verbsDir = path.join(this.rootDir, VERBS_DIR)
-  this.metadataDir = path.join(this.rootDir, METADATA_DIR)
-  this.indexDir = path.join(this.rootDir, INDEX_DIR)
-}
-```
-
-However, the path module was being loaded asynchronously via dynamic imports:
-
-```typescript
-try {
-  // Using dynamic imports to avoid issues in browser environments
-  const fsPromise = import('fs')
-  const pathPromise = import('path')
-
-  Promise.all([fsPromise, pathPromise]).then(([fsModule, pathModule]) => {
-    fs = fsModule
-    path = pathModule.default
-  }).catch(error => {
-    console.error('Failed to load Node.js modules:', error)
-  })
-} catch (error) {
-  console.error(
-    'FileSystemStorage: Failed to load Node.js modules. This adapter is not supported in this environment.',
-    error
-  )
-}
-```
-
-The fix:
-1. Modified the constructor to only store the rootDirectory and defer path operations
-2. Updated the init() method to initialize directory paths when the path module is guaranteed to be loaded
-
-This ensures that path operations are only performed when the path module is available, preventing the "Cannot read properties of undefined (reading 'join')" error.
-
-## Statistics Optimizations Implementation
-
-### Overview
-
-This section summarizes the changes made to implement statistics optimizations across all storage adapters in the Brainy project. The optimizations were originally implemented for the s3CompatibleStorage adapter and have now been extended to all storage adapters.
-
-### Changes Made
-
-#### 1. BaseStorageAdapter Enhancements
-
-The BaseStorageAdapter class was refactored to include shared optimizations:
-
-- Added in-memory caching of statistics data
-- Implemented batched updates with adaptive flush timing
-- Added error handling and retry mechanisms
-- Updated core statistics methods to use the new caching and batching approach
-
-Specific changes:
-- Added properties for caching and batch update management
-- Implemented `scheduleBatchUpdate()` and `flushStatistics()` methods
-- Updated `saveStatistics()`, `getStatistics()`, `incrementStatistic()`, `decrementStatistic()`, and `updateHnswIndexSize()` methods
-
-#### 2. Storage Adapter Updates
-
-##### FileSystemStorage
-
-- Implemented time-based partitioning for statistics files
-- Added fallback mechanisms to check multiple storage locations
-- Maintained backward compatibility with legacy statistics files
-
-##### MemoryStorage
-
-- Updated to be compatible with the BaseStorageAdapter changes
-- Leverages the in-memory nature of this adapter for efficient caching
-
-##### OPFSStorage (Origin Private File System)
-
-- Implemented time-based partitioning for statistics files
-- Added fallback mechanisms to check multiple storage locations
-- Maintained backward compatibility with legacy statistics files
-
-#### 3. Documentation Updates
-
-- Updated statistics.md to reflect that optimizations are implemented across all storage adapters
-- Added a new section describing the implementation across different adapter types
-
-### Benefits
-
-These changes provide several benefits:
-
-1. **Improved Performance**: Reduced storage operations through caching and batching
-2. **Better Scalability**: Time-based partitioning helps avoid rate limits and reduces contention
-3. **Historical Data**: Daily statistics files provide a historical record of database usage
-4. **Consistent Experience**: All storage adapters now provide the same optimizations
-5. **Backward Compatibility**: Legacy statistics files are still supported
-
-### Testing
-
-The changes have been tested to ensure they don't break existing functionality. The specific statistics test requires additional setup (dotenv package and AWS credentials) but general tests are passing.
-
-### Conclusion
-
-The statistics optimizations originally implemented for the s3CompatibleStorage adapter have been successfully extended to all storage adapters in the Brainy project. This ensures consistent performance and scalability across different storage backends.

CHANGES_SUMMARY.md

@@ -1,63 +0,0 @@
-# Statistics Optimizations Implementation Summary
-
-## Overview
-
-This document summarizes the changes made to implement statistics optimizations across all storage adapters in the Brainy project. The optimizations were originally implemented for the s3CompatibleStorage adapter and have now been extended to all storage adapters.
-
-## Changes Made
-
-### 1. BaseStorageAdapter Enhancements
-
-The BaseStorageAdapter class was refactored to include shared optimizations:
-
-- Added in-memory caching of statistics data
-- Implemented batched updates with adaptive flush timing
-- Added error handling and retry mechanisms
-- Updated core statistics methods to use the new caching and batching approach
-
-Specific changes:
-- Added properties for caching and batch update management
-- Implemented `scheduleBatchUpdate()` and `flushStatistics()` methods
-- Updated `saveStatistics()`, `getStatistics()`, `incrementStatistic()`, `decrementStatistic()`, and `updateHnswIndexSize()` methods
-
-### 2. Storage Adapter Updates
-
-#### FileSystemStorage
-
-- Implemented time-based partitioning for statistics files
-- Added fallback mechanisms to check multiple storage locations
-- Maintained backward compatibility with legacy statistics files
-
-#### MemoryStorage
-
-- Updated to be compatible with the BaseStorageAdapter changes
-- Leverages the in-memory nature of this adapter for efficient caching
-
-#### OPFSStorage (Origin Private File System)
-
-- Implemented time-based partitioning for statistics files
-- Added fallback mechanisms to check multiple storage locations
-- Maintained backward compatibility with legacy statistics files
-
-### 3. Documentation Updates
-
-- Updated statistics.md to reflect that optimizations are implemented across all storage adapters
-- Added a new section describing the implementation across different adapter types
-
-## Benefits
-
-These changes provide several benefits:
-
-1. **Improved Performance**: Reduced storage operations through caching and batching
-2. **Better Scalability**: Time-based partitioning helps avoid rate limits and reduces contention
-3. **Historical Data**: Daily statistics files provide a historical record of database usage
-4. **Consistent Experience**: All storage adapters now provide the same optimizations
-5. **Backward Compatibility**: Legacy statistics files are still supported
-
-## Testing
-
-The changes have been tested to ensure they don't break existing functionality. The specific statistics test requires additional setup (dotenv package and AWS credentials) but general tests are passing.
-
-## Conclusion
-
-The statistics optimizations originally implemented for the s3CompatibleStorage adapter have been successfully extended to all storage adapters in the Brainy project. This ensures consistent performance and scalability across different storage backends.

CLAUDE.md

@@ -0,0 +1,208 @@
+# Brainy - Claude Code Project Guide
+
+This file provides guidance for Claude Code (and human contributors) when working on the Brainy codebase.
+
+## Cross-Project Coordination
+
+Handoff file: `/home/dpsifr/.strategy/PLATFORM-HANDOFF.md`
+
+**At session START:** Read the handoff. Find rows where Owner = Brainy. Act on those first.
+
+**At session END:** Mark completed actions ✅, delete rows you finished, delete threads with zero remaining actions. File must not grow. **If you shipped anything consumers need to know about, update `RELEASES.md` before closing.**
+
+**Brainy's current open actions:** None. MIT open-source — no platform-specific actions.
+
+**Current version:** run `npm view @soulcraft/brainy version` (never trust a hardcoded number here — this line went stale for months); consumer-facing changes tracked in `RELEASES.md`
+
+---
+
+## Project Overview
+
+Brainy is a Universal Knowledge Protocol -- a Triple Intelligence database that combines vector similarity search, graph traversal, and metadata filtering into a single TypeScript library. Published as `@soulcraft/brainy` on npm under the MIT license.
+
+## Getting Started
+
+```bash
+npm install           # Install dependencies
+npm run build         # Build the project
+npm test              # Run test suite (Vitest)
+```
+
+## Architecture
+
+Full architecture reference: `.claude/skills/architecture.md`
+
+### Core Systems
+- **Storage** (`src/storage/`): Pluggable storage backends via StorageAdapter interface (`src/coreTypes.ts`)
+- **Vector Search** (`src/hnsw/`): HNSW approximate nearest neighbor search
+- **Graph Engine** (`src/graph/`): Relationship traversal with adjacency index and pathfinding
+- **Metadata Index** (`src/utils/metadataIndex.ts`): O(1) exact match, O(log n) range queries
+- **Triple Intelligence** (`src/triple/`): Unified query combining all three intelligence types
+- **Aggregation Engine** (`src/aggregation/`): Write-time incremental SUM/COUNT/AVG/MIN/MAX with GROUP BY and time windows
+- **Virtual Filesystem** (`src/vfs/`): Full VFS with semantic search
+
+### Type System
+- **NounType** (42 types): Entity classification -- Person, Concept, Collection, Document, Task, etc.
+- **VerbType** (127 types): Relationship types -- Contains, RelatedTo, PartOf, Creates, DependsOn, etc.
+- Defined in `src/types/graphTypes.ts`
+
+## Code Standards
+
+### TypeScript
+- Strict mode enabled
+- Target: ES2020, NodeNext module resolution
+- All new code must be TypeScript
+- Follow existing patterns -- read related code before writing
+
+### Quality
+- All code must compile without errors
+- All code must have working tests that exercise real behavior
+- No stub returns (`return {} as any`)
+- No incomplete implementations with TODO comments
+- If something can't be fully implemented, throw an explicit error rather than faking it
+
+### Verification Before Code Changes
+1. Check that interfaces and methods actually exist before using them
+2. Check that type properties are in the type definitions
+3. Run `npm test` -- tests must pass
+4. Run `npm run build` -- build must succeed
+
+### Testing
+- Framework: Vitest
+- Tests in `tests/` (unit, integration, benchmarks, comprehensive)
+- Use in-memory storage for speed where possible
+- Tests must exercise real behavior, not mock it
+- Benchmarks are in `tests/benchmarks/` (not tests/performance/)
+
+## Commit Conventions
+
+Use [Conventional Commits](https://www.conventionalcommits.org/):
+
+```
+feat: add new feature        (minor version bump)
+fix: resolve bug             (patch version bump)
+docs: update documentation   (patch version bump)
+perf: improve performance    (patch version bump)
+refactor: restructure code   (patch version bump)
+test: add/update tests       (patch version bump)
+```
+
+**Important:** Never use `BREAKING CHANGE` in commit messages. Major version bumps are manual decisions only (`npm run release:major`).
+
+## Docs Pipeline — soulcraft.com/docs
+
+Docs in `docs/**/*.md` are published with the npm package (included in `files`) and synced to soulcraft.com/docs on every portal deploy. Frontmatter controls what appears publicly.
+
+### Docs check triggers
+
+Run the docs check whenever the user says ANY of:
+- "commit, publish, release" / "release" / "publish"
+- "update the docs" / "make sure docs are accurate" / "check the docs"
+- "review docs" / "clean up docs"
+
+### Pre-release docs check (MANDATORY before every release)
+
+When the user says "commit, publish, release" or any variation, **before committing**:
+
+1. **Scan all files changed in this session** (and any recently added `docs/*.md` files)
+2. For each changed/new doc, decide: is this useful to external users?
+   - **Yes** → ensure it has complete frontmatter (add or update it)
+   - **No** (internal, migration, dev-only) → ensure it has no frontmatter or `public: false`
+3. For docs that already have frontmatter, verify:
+   - `description` still matches the actual content
+   - `next` links still exist and are still the right follow-up pages
+   - `title` matches the doc's h1
+4. Include frontmatter changes in the commit
+
+### Frontmatter format
+
+```yaml
+---
+title: Human-readable title
+slug: category/page-name          # URL: soulcraft.com/docs/category/page-name
+public: true                      # false or absent = not published
+category: getting-started | concepts | guides | api
+template: guide | concept | api   # controls layout on soulcraft.com
+order: 1                          # sidebar position within category (lower = first)
+description: One sentence. What this doc covers and why it matters.
+next:                             # "Next steps" links shown at bottom of page
+  - category/other-slug
+---
+```
+
+### Category guide
+
+| category | use for |
+|----------|---------|
+| `getting-started` | installation, quick start, first steps |
+| `concepts` | how the system works, mental models |
+| `guides` | how to do specific things, recipes |
+| `api` | method reference, signatures, parameters |
+
+### What stays internal (no frontmatter / `public: false`)
+
+- Release guides, developer learning paths
+- Migration guides for old versions (v3→v4, v5.11)
+- Architecture analysis docs (clustering algorithms, etc.)
+- Anything in `docs/internal/`
+- Deployment/ops/cost docs (cloud-run, kubernetes, cost-optimization)
+
+## Release Process
+
+Fully automated via `scripts/release.sh`:
+
+```bash
+npm run release:dry          # Preview (no changes)
+npm run release:patch        # Bug fixes
+npm run release:minor        # New features
+npm run release:major        # Breaking changes (rare, manual decision)
+```
+
+The script: verifies clean git state, builds, tests, bumps version, updates CHANGELOG.md, commits, tags, pushes, publishes to npm, and creates a GitHub release.
+
+After a successful release, remind the user:
+> "Published. Deploy portal to pick up the new docs → go to the portal project and deploy."
+
+Do NOT deploy portal from here. Portal is always deployed separately from within the portal project.
+
+## Closed-Source Product Names — HARD RULE
+
+Brainy is the only Soulcraft open-source project. Nothing in this repo — code, JSDoc, tests,
+docs, RELEASES.md, CHANGELOG.md, commit messages — may reference closed-source Soulcraft
+products by name (Workshop, Venue, Memory, Muse, Hall, Forge, Academy, Pulse, Heart,
+Collective, SDK) or by their specific class/method names (`BookingDraftService`,
+`getDemandHeatmap`, `systemKind`, etc.).
+
+When recording a consumer-reported bug, regression scenario, or release note:
+- Refer to "a consumer", "a downstream application", "a production deployment", or "an
+  internal report" — never name the product.
+- All doc examples must use generic domain values (`'employee'`, `'customer'`, `'invoice'`,
+  `'milestone'`, `OrderService`, `/orders/...`), not product-specific schemas.
+- Internal session artifacts (`.strategy/`, `~/.claude/plans/`, handoff files outside the
+  repo) MAY name products — those are not public.
+
+If you catch yourself typing a product name into a tracked file, stop and rephrase.
+
+## Performance Claims
+
+When documenting performance characteristics:
+- **MEASURED**: Cite the test file and line number
+- **PROJECTED**: Clearly label as extrapolated from tested scale
+- Never claim a performance figure without context or evidence
+
+## Debugging
+
+When a bug persists through 2+ fix attempts, switch to systematic debugging:
+1. Add comprehensive logging at every step
+2. Test with production-like data
+3. Trace the complete execution path
+4. Check both library code and consumer code
+5. Verify with actual test execution before declaring fixed
+
+## Key Paths
+
+- Main class: `src/brainy.ts`
+- Public API: `src/index.ts` (38+ exports)
+- Storage interface: `src/coreTypes.ts`
+- Type definitions: `src/types/`
+- Strategy/planning docs: `.strategy/` (gitignored, not public)

CNAME

@@ -1 +0,0 @@
-demo.soulcraft.com

CODE_OF_CONDUCT.md

@@ -1,128 +0,0 @@
-# Contributor Covenant Code of Conduct
-
-## Our Pledge
-
-We as members, contributors, and leaders pledge to make participation in our
-community a harassment-free experience for everyone, regardless of age, body
-size, visible or invisible disability, ethnicity, sex characteristics, gender
-identity and expression, level of experience, education, socio-economic status,
-nationality, personal appearance, race, religion, or sexual identity
-and orientation.
-
-We pledge to act and interact in ways that contribute to an open, welcoming,
-diverse, inclusive, and healthy community.
-
-## Our Standards
-
-Examples of behavior that contributes to a positive environment for our
-community include:
-
-* Demonstrating empathy and kindness toward other people
-* Being respectful of differing opinions, viewpoints, and experiences
-* Giving and gracefully accepting constructive feedback
-* Accepting responsibility and apologizing to those affected by our mistakes,
-  and learning from the experience
-* Focusing on what is best not just for us as individuals, but for the
-  overall community
-
-Examples of unacceptable behavior include:
-
-* The use of sexualized language or imagery, and sexual attention or
-  advances of any kind
-* Trolling, insulting or derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or email
-  address, without their explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
-  professional setting
-
-## Enforcement Responsibilities
-
-Project maintainers are responsible for clarifying and enforcing our standards of
-acceptable behavior and will take appropriate and fair corrective action in
-response to any behavior that they deem inappropriate, threatening, offensive,
-or harmful.
-
-Project maintainers have the right and responsibility to remove, edit, or reject
-comments, commits, code, wiki edits, issues, and other contributions that are
-not aligned with this Code of Conduct, and will communicate reasons for moderation
-decisions when appropriate.
-
-## Scope
-
-This Code of Conduct applies within all community spaces, and also applies when
-an individual is officially representing the community in public spaces.
-Examples of representing our community include using an official e-mail address,
-posting via an official social media account, or acting as an appointed
-representative at an online or offline event.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported to the project maintainers responsible for enforcement at
-conduct@soulcraft.com.
-All complaints will be reviewed and investigated promptly and fairly.
-
-All project maintainers are obligated to respect the privacy and security of the
-reporter of any incident.
-
-## Enforcement Guidelines
-
-Project maintainers will follow these Community Impact Guidelines in determining
-the consequences for any action they deem in violation of this Code of Conduct:
-
-### 1. Correction
-
-**Community Impact**: Use of inappropriate language or other behavior deemed
-unprofessional or unwelcome in the community.
-
-**Consequence**: A private, written warning from project maintainers, providing
-clarity around the nature of the violation and an explanation of why the
-behavior was inappropriate. A public apology may be requested.
-
-### 2. Warning
-
-**Community Impact**: A violation through a single incident or series
-of actions.
-
-**Consequence**: A warning with consequences for continued behavior. No
-interaction with the people involved, including unsolicited interaction with
-those enforcing the Code of Conduct, for a specified period of time. This
-includes avoiding interactions in community spaces as well as external channels
-like social media. Violating these terms may lead to a temporary or
-permanent ban.
-
-### 3. Temporary Ban
-
-**Community Impact**: A serious violation of community standards, including
-sustained inappropriate behavior.
-
-**Consequence**: A temporary ban from any sort of interaction or public
-communication with the community for a specified period of time. No public or
-private interaction with the people involved, including unsolicited interaction
-with those enforcing the Code of Conduct, is allowed during this period.
-Violating these terms may lead to a permanent ban.
-
-### 4. Permanent Ban
-
-**Community Impact**: Demonstrating a pattern of violation of community
-standards, including sustained inappropriate behavior, harassment of an
-individual, or aggression toward or disparagement of classes of individuals.
-
-**Consequence**: A permanent ban from any sort of public interaction within
-the community.
-
-## Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant][homepage],
-version 2.0, available at
-https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
-
-Community Impact Guidelines were inspired by [Mozilla's code of conduct
-enforcement ladder](https://github.com/mozilla/diversity).
-
-[homepage]: https://www.contributor-covenant.org
-
-For answers to common questions about this code of conduct, see the FAQ at
-https://www.contributor-covenant.org/faq. Translations are available at
-https://www.contributor-covenant.org/translations.

CONCURRENCY_ANALYSIS.md

@@ -1,207 +0,0 @@
-# Brainy Concurrency and Performance Analysis
-
-## Issue Summary
-Multiple web services are running Brainy with shared S3 storage, causing performance and contention issues in high-throughput scenarios.
-
-## Identified Problems
-
-### 1. Statistics Handling Issues
-
-#### Race Conditions in Statistics Updates
-- **Location**: `S3CompatibleStorage.scheduleBatchUpdate()` and `flushStatistics()`
-- **Problem**: Multiple service instances update statistics independently without coordination
-- **Impact**: Lost updates, inconsistent statistics, data corruption
-
-#### Cache Inconsistency
-- **Location**: `S3CompatibleStorage.statisticsCache`
-- **Problem**: Each instance maintains its own statistics cache
-- **Impact**: Statistics displayed by search service may be stale or incorrect
-
-#### Timer-based Batching Issues
-- **Location**: `S3CompatibleStorage.scheduleBatchUpdate()`
-- **Problem**: setTimeout-based batching with no coordination between instances
-- **Impact**: Statistics updates can be delayed or lost during service restarts
-
-### 2. Index Synchronization Issues
-
-#### Inefficient Full Scans
-- **Location**: `BrainyData.checkForUpdates()`
-- **Problem**: Calls `getAllNouns()` on every update check
-- **Impact**: Extremely expensive for large datasets, poor scalability
-
-#### Race Conditions in Index Updates
-- **Location**: `BrainyData.checkForUpdates()` lines 438-456
-- **Problem**: Multiple instances can add the same nouns simultaneously
-- **Impact**: Inconsistent index state, wasted resources
-
-#### No Distributed Locking
-- **Location**: Throughout the codebase
-- **Problem**: No mechanism to coordinate updates between multiple instances
-- **Impact**: Data corruption, inconsistent state
-
-### 3. Memory and Performance Issues
-
-#### Memory Usage Tracking Race Conditions
-- **Location**: `HNSWIndexOptimized.addItem()` lines 347-348
-- **Problem**: `this.memoryUsage += totalMemory` and `this.vectorCount++` are not thread-safe
-- **Impact**: Incorrect memory usage calculations, potential memory leaks
-
-#### Duplicate Index Maintenance
-- **Location**: Each service instance
-- **Problem**: Every instance maintains a complete copy of the HNSW index
-- **Impact**: Excessive memory usage, slow startup times
-
-#### Polling-based Updates
-- **Location**: `BrainyData.startRealtimeUpdates()`
-- **Problem**: Uses setInterval for periodic checks instead of event-driven updates
-- **Impact**: High latency, unnecessary resource usage
-
-### 4. Storage Contention Issues
-
-#### Concurrent S3 Writes
-- **Location**: `S3CompatibleStorage.saveNode()`, `saveEdge()`, etc.
-- **Problem**: No coordination for concurrent writes to the same S3 objects
-- **Impact**: Data corruption, lost writes
-
-#### No Optimistic Locking
-- **Location**: All storage operations
-- **Problem**: No mechanism to detect and handle concurrent modifications
-- **Impact**: Last-writer-wins scenarios, data loss
-
-## Recommended Solutions
-
-### 1. Implement Distributed Locking
-
-```typescript
-// Add to S3CompatibleStorage
-private async acquireLock(lockKey: string, ttl: number = 30000): Promise<boolean> {
-    const lockObject = `locks/${lockKey}`;
-    const lockValue = `${Date.now()}_${Math.random()}`;
-    
-    try {
-        await this.s3Client!.send(new PutObjectCommand({
-            Bucket: this.bucketName,
-            Key: lockObject,
-            Body: lockValue,
-            ContentType: 'text/plain',
-            Metadata: {
-                'expires-at': (Date.now() + ttl).toString()
-            }
-        }));
-        return true;
-    } catch (error) {
-        if (error.name === 'ConditionalCheckFailedException') {
-            return false; // Lock already exists
-        }
-        throw error;
-    }
-}
-```
-
-### 2. Event-Driven Index Updates
-
-```typescript
-// Add to BrainyData
-private async setupEventDrivenUpdates(): Promise<void> {
-    // Use S3 event notifications or implement a change log
-    const changeLogKey = `${this.indexPrefix}change-log.json`;
-    
-    // Poll change log instead of full data scan
-    setInterval(async () => {
-        const changes = await this.getChangesSince(this.lastUpdateTime);
-        await this.applyChanges(changes);
-    }, this.realtimeUpdateConfig.interval);
-}
-```
-
-### 3. Optimized Statistics Handling
-
-```typescript
-// Add to S3CompatibleStorage
-private async atomicStatisticsUpdate(updateFn: (stats: StatisticsData) => StatisticsData): Promise<void> {
-    const lockKey = 'statistics-update';
-    const lockAcquired = await this.acquireLock(lockKey);
-    
-    if (!lockAcquired) {
-        // Another instance is updating, skip this update
-        return;
-    }
-    
-    try {
-        // Read current statistics
-        const currentStats = await this.getStatisticsData();
-        
-        // Apply update
-        const updatedStats = updateFn(currentStats);
-        
-        // Write back with version check
-        await this.saveStatisticsWithVersionCheck(updatedStats);
-    } finally {
-        await this.releaseLock(lockKey);
-    }
-}
-```
-
-### 4. Shared Index Architecture
-
-```typescript
-// New class: SharedHNSWIndex
-export class SharedHNSWIndex {
-    private localCache: Map<string, VectorDocument> = new Map();
-    private lastSyncTime: number = 0;
-    
-    async search(queryVector: Vector, k: number): Promise<Array<[string, number]>> {
-        // Ensure local cache is up to date
-        await this.syncIfNeeded();
-        
-        // Perform search on local cache
-        return this.performLocalSearch(queryVector, k);
-    }
-    
-    private async syncIfNeeded(): Promise<void> {
-        const now = Date.now();
-        if (now - this.lastSyncTime > this.syncInterval) {
-            await this.syncFromStorage();
-            this.lastSyncTime = now;
-        }
-    }
-}
-```
-
-### 5. Change Log Implementation
-
-```typescript
-// Add to storage adapters
-interface ChangeLogEntry {
-    timestamp: number;
-    operation: 'add' | 'update' | 'delete';
-    entityType: 'noun' | 'verb';
-    entityId: string;
-    data?: any;
-}
-
-private async appendToChangeLog(entry: ChangeLogEntry): Promise<void> {
-    const changeLogKey = `change-log/${Date.now()}-${Math.random()}.json`;
-    await this.s3Client!.send(new PutObjectCommand({
-        Bucket: this.bucketName,
-        Key: changeLogKey,
-        Body: JSON.stringify(entry),
-        ContentType: 'application/json'
-    }));
-}
-```
-
-## Implementation Priority
-
-1. **High Priority**: Implement distributed locking for statistics updates
-2. **High Priority**: Add change log mechanism for efficient index synchronization
-3. **Medium Priority**: Implement shared index architecture
-4. **Medium Priority**: Add optimistic locking for storage operations
-5. **Low Priority**: Optimize memory usage tracking
-
-## Performance Improvements Expected
-
-- **Statistics Updates**: 90% reduction in conflicts, near real-time updates
-- **Index Synchronization**: 95% reduction in data transfer, faster updates
-- **Memory Usage**: 70% reduction per service instance
-- **Search Latency**: 50% improvement due to better cache locality

CONCURRENCY_IMPLEMENTATION_SUMMARY.md

@@ -1,115 +0,0 @@
-# Concurrency Implementation Summary
-
-## Overview
-This document summarizes all the concurrency improvements that have been implemented based on the recommendations in CONCURRENCY_ANALYSIS.md.
-
-## ✅ Completed High Priority Implementations
-
-### 1. Distributed Locking for Statistics Updates
-**Location**: `S3CompatibleStorage.flushStatistics()`
-**Implementation**:
-- Added `acquireLock()` and `releaseLock()` methods using S3 objects as locks
-- Implemented lock timeout (15 seconds) and automatic cleanup
-- Statistics updates now use distributed locking to prevent race conditions
-- Graceful handling when another instance is updating statistics
-
-### 2. Change Log Mechanism for Efficient Index Synchronization
-**Location**: `S3CompatibleStorage` and `BrainyData.checkForUpdates()`
-**Implementation**:
-- Added `ChangeLogEntry` interface for tracking data modifications
-- Implemented `appendToChangeLog()` method that logs all CRUD operations
-- Added `getChangesSince()` method for retrieving changes since a timestamp
-- Updated `BrainyData.checkForUpdates()` to use change log instead of expensive full scans
-- Fallback mechanism for storage adapters that don't support change logs
-- Automatic cleanup of old change log entries
-
-### 3. Thread-Safe Memory Usage Tracking
-**Location**: `HNSWIndexOptimized`
-**Implementation**:
-- Added `memoryUpdateLock` using Promise chaining for thread safety
-- Implemented `updateMemoryUsage()` and `getMemoryUsage()` methods
-- Updated `addItem()`, `removeItem()`, and `clear()` methods to use thread-safe updates
-- Prevents race conditions in memory usage calculations
-
-### 4. Atomic Statistics Updates with Merge Strategy
-**Location**: `S3CompatibleStorage.flushStatistics()`
-**Implementation**:
-- Read current statistics from storage before updating
-- Merge local changes with storage statistics to prevent data loss
-- Use distributed locking to ensure atomic updates
-- Proper error handling and lock cleanup in finally blocks
-
-### 5. Comprehensive Change Log Integration
-**Location**: All CRUD operations in `S3CompatibleStorage`
-**Implementation**:
-- `saveNode()`: Logs 'add' operations for nouns
-- `saveEdge()`: Logs 'add' operations for verbs
-- `deleteNode()`: Logs 'delete' operations for nouns
-- `deleteEdge()`: Logs 'delete' operations for verbs
-- `saveMetadata()`: Logs metadata changes
-- All operations include timestamp, operation type, entity type, and relevant data
-
-## ✅ Performance Improvements Achieved
-
-Based on the original analysis expectations:
-
-1. **Statistics Updates**: 90% reduction in conflicts achieved through distributed locking
-2. **Index Synchronization**: 95% reduction in data transfer achieved through change log mechanism
-3. **Memory Usage Tracking**: Race conditions eliminated through thread-safe updates
-4. **Search Performance**: Improved through better cache consistency and reduced contention
-
-## 📊 Storage Adapter Analysis
-
-### S3CompatibleStorage ✅ FULLY IMPLEMENTED
-- **Risk Level**: HIGH (multi-instance distributed deployment)
-- **Status**: All concurrency improvements implemented and tested
-- **Features**: Distributed locking, change logs, atomic updates, lock cleanup
-
-### FileSystemStorage 📋 ANALYSIS COMPLETE
-- **Risk Level**: MEDIUM (multi-process scenarios)
-- **Status**: Analysis complete, improvements optional for typical use cases
-- **Recommendation**: File-based locking for multi-process scenarios (not critical)
-
-### OPFSStorage 📋 ANALYSIS COMPLETE
-- **Risk Level**: LOW-MEDIUM (multi-tab browser scenarios)
-- **Status**: Analysis complete, improvements optional
-- **Recommendation**: Browser-based locking for multi-tab scenarios (not critical)
-
-### MemoryStorage 📋 ANALYSIS COMPLETE
-- **Risk Level**: VERY LOW (single-process in-memory)
-- **Status**: No changes needed
-- **Recommendation**: No improvements required for typical use cases
-
-## 🧪 Testing Results
-
-All implementations have been tested and verified:
-- **Test Files**: 20 passed | 1 skipped (21)
-- **Tests**: 178 passed | 18 skipped (196)
-- **Duration**: 22.18s
-- **Status**: ✅ All tests passing
-
-## 📈 Impact Assessment
-
-### Before Implementation
-- Race conditions in statistics updates causing data corruption
-- Inefficient full scans on every index update check
-- Memory usage tracking race conditions
-- No coordination between multiple service instances
-
-### After Implementation
-- Distributed coordination prevents data corruption
-- Change log mechanism provides 95% reduction in data transfer
-- Thread-safe memory tracking eliminates race conditions
-- Robust multi-instance deployment support
-
-## 🎯 Conclusion
-
-All high-priority concurrency improvements from CONCURRENCY_ANALYSIS.md have been successfully implemented and tested. The system now provides:
-
-1. **Robust Multi-Instance Support**: Multiple web services can safely share S3 storage
-2. **Efficient Synchronization**: Change log mechanism eliminates expensive full scans
-3. **Data Integrity**: Distributed locking prevents race conditions and data corruption
-4. **Performance Optimization**: Significant improvements in high-throughput scenarios
-5. **Backward Compatibility**: Fallback mechanisms ensure compatibility with all storage types
-
-The implementation addresses all identified concurrency issues while maintaining system stability and performance.

CONTRIBUTING.md

@@ -1,97 +1,66 @@
-<div align="center">
-<img src="./brainy.png" alt="Brainy Logo" width="200"/>
-
 # Contributing to Brainy
 
-</div>
+Brainy is MIT-licensed and genuinely open to outside contributions. This page
+is the honest, current path — please don't rely on older instructions you
+may find elsewhere in the repo's history.
 
-Thank you for your interest in contributing to Brainy! This document provides guidelines and instructions for
-contributing to the project.
+## Where the project lives
 
-We welcome contributions of all kinds, including bug fixes, feature additions, documentation improvements, and more.
-By participating in this project, you agree to abide by our [Code of Conduct](CODE_OF_CONDUCT.md).
+The source of truth is a self-hosted forge: **source.soulcraft.com/soulcraft/brainy**.
+It's anonymously readable and cloneable — no account needed to browse, clone,
+or build.
 
-## Commit Message Guidelines
+## How to contribute
 
-When contributing to this project, please write clear and descriptive commit messages that explain the purpose of your
-changes. Good commit messages help maintainers understand your contributions and make the review process smoother.
+**Found a bug, or have an idea?** Email **brainy@soulcraft.com**. No account,
+no ceremony — you'll get a receipt, and it goes to a human.
 
-### Best Practices
+**Want to send a patch?** Two ways, both first-class:
 
-- Keep the first line concise (ideally under 50 characters)
-- Use the imperative mood ("Add feature" not "Added feature")
-- Reference issues and pull requests where appropriate
-- When necessary, provide more detailed explanations in the commit body
+- **Email a patch.** Run `git format-patch` against your change and email the
+  output to **brainy@soulcraft.com**. This is a genuinely supported path, not
+  a fallback — plenty of good contributions arrive this way.
+- **Open a pull request on the forge.** Request an account at
+  **source.soulcraft.com** (registration is request-with-approval, so allow
+  a little lag), clone, push a branch, and open a PR there. Maintainers
+  review and land it.
 
-### Examples
+Either way, for anything beyond a small fix, opening an issue first (email is
+fine) to talk through the approach saves everyone rework.
 
-```
-Add vector normalization option
-Fix distance calculation in HNSW search
-Update API documentation
-Add support for IndexedDB storage
-Change API parameter order
-Simplify vector comparison logic
-Update build dependencies
-```
-
-## Pull Request Process
-
-1. Ensure your code follows the project's coding standards
-2. Update the documentation if necessary
-3. Use conventional commit messages in your PR
-4. Your PR will be reviewed by maintainers and merged if approved
-
-## Development Setup
-
-1. Fork and clone the repository
-2. Install dependencies: `npm install`
-3. Build the project: `npm run build`
-
-## Code Style
-
-This project uses ESLint and Prettier for code formatting and style checking. The configuration can be found in the `package.json` file. Please ensure your code follows these standards:
-
-- Use 2 spaces for indentation
-- Use single quotes for strings
-- No semicolons
-- Trailing commas are not used
-- Maximum line length is 80 characters
-
-You can check your code style by running:
-```bash
-npm run check:style
-```
-
-This will run all code style checks, including a specific check for semicolons.
-
-You can also run individual checks:
+## Development setup
 
 ```bash
-npm run lint         # Run ESLint to check for code issues
-npm run lint:fix     # Automatically fix linting issues
-npm run format       # Format your code with Prettier
-npm run check-format # Check if your code is properly formatted
+git clone https://source.soulcraft.com/soulcraft/brainy.git
+cd brainy
+npm install
+npm run build
+npm test
 ```
 
-## Branching Strategy
+Tests run on [Vitest](https://vitest.dev/). `npm test` runs the unit suite;
+see `package.json` for `test:integration`, `test:coverage`, and friends.
 
-- `main` - The main branch contains the latest stable release
-- `develop` - The development branch contains the latest development changes
-- Feature branches - Create a branch from `develop` for your feature or fix
+## Standards
 
-When working on a new feature or fix:
-1. Create a new branch from `develop` with a descriptive name (e.g., `feature/add-vector-normalization` or `fix/distance-calculation`)
-2. Make your changes in that branch
-3. Submit a pull request to merge your branch into `develop`
+- **Strict TypeScript.** No `any` escape hatches to dodge the type checker.
+- **Tests exercise real behavior.** No mocking away the thing you're supposed
+  to be testing.
+- **No stubs, no TODO-code.** If something can't be finished, say so and
+  leave it out — don't merge a placeholder.
+- **JSDoc on every exported function, class, and type.**
+- **[Conventional Commits](https://www.conventionalcommits.org/).** `feat:`,
+  `fix:`, `docs:`, `perf:`, `refactor:`, `test:`, `chore:`. Never
+  `BREAKING CHANGE` in a commit message — major version bumps are a separate,
+  deliberate decision.
+- **Performance claims are measured or labeled projected.** If a PR or its
+  description states a number, cite the benchmark that produced it (see
+  [docs/performance-envelopes.md](docs/performance-envelopes.md) for the
+  pattern). Don't state an estimate as if it were measured.
 
-## Issue Reporting
+## License
 
-Before submitting a new issue, please search existing issues to avoid duplicates.
+Brainy is [MIT licensed](LICENSE). Contributions are accepted under the same
+license — there's no CLA to sign.
 
-- For bugs, use the bug report template
-- For feature requests, use the feature request template
-- Be as detailed as possible in your description
-- Include code examples, error messages, and screenshots if applicable
-
-Thank you for contributing to Brainy!
+Thank you for considering a contribution.

DEVELOPERS.md

@@ -1,250 +0,0 @@
-# Brainy Developer Guide
-
-<div align="center">
-<img src="./brainy.png" alt="Brainy Logo" width="200"/>
-</div>
-
-This document contains detailed information for developers working with Brainy, including building, testing, and
-publishing instructions.
-
-## Table of Contents
-
-- [Build System](#build-system)
-- [Testing](#testing)
-    - [Testing All Environments](#testing-all-environments)
-    - [Testing the CLI Package Locally](#testing-the-cli-package-locally)
-- [Publishing](#publishing)
-    - [Publishing the CLI Package](#publishing-the-cli-package)
-- [Development Usage](#development-usage)
-- [Node.js 24 Optimizations](#nodejs-24-optimizations)
-- [Development Workflow](#development-workflow)
-- [Reporting Issues](#reporting-issues)
-- [Code Style Guidelines](#code-style-guidelines)
-- [Badge Maintenance](#badge-maintenance)
-
-## Build System
-
-Brainy uses a modern build system that optimizes for both Node.js and browser environments:
-
-1. **ES Modules**
-    - Built as ES modules for maximum compatibility
-    - Works in modern browsers and Node.js environments
-    - Separate optimized builds for browser and Node.js
-
-2. **Environment-Specific Builds**
-    - **Node.js Build**: Optimized for server environments with full functionality
-    - **Browser Build**: Optimized for browser environments with reduced bundle size
-    - **CLI Build**: Separate build for command-line interface functionality
-    - Conditional exports in package.json for automatic environment detection
-
-3. **Modular Architecture**
-    - Core functionality and CLI are built separately
-    - CLI (4MB) is only included when explicitly imported or used from command line
-    - Reduced bundle size for browser and Node.js applications
-
-4. **Environment Detection**
-    - Automatically detects whether it's running in a browser or Node.js
-    - Loads appropriate dependencies and functionality based on the environment
-    - Provides consistent API across all environments
-
-5. **TypeScript**
-    - Written in TypeScript for type safety and better developer experience
-    - Generates type definitions for TypeScript users
-    - Compiled to ES2020 for modern JavaScript environments
-
-6. **Build Scripts**
-    - `npm run build`: Builds the core library without CLI
-    - `npm run build:browser`: Builds the browser-optimized version
-    - `npm run build:cli`: Builds the CLI version (only needed for CLI usage)
-    - `npm run prepare:cli`: Builds the CLI for command-line usage
-    - `npm run demo`: Builds both core library and browser versions and starts a demo server
-    - GitHub Actions workflow: Automatically deploys the demo directory to GitHub Pages when pushing to the main branch
-
-## Testing
-
-### Test Scripts
-
-Brainy provides several test scripts for different testing scenarios:
-
-```bash
-# Run all tests
-npm test
-
-# Run tests with comprehensive reporting
-npm run test:report
-
-# Run tests in watch mode
-npm test:watch
-
-# Run tests with UI
-npm test:ui
-
-# Run specific test suites
-npm run test:node
-npm run test:browser
-npm run test:core
-
-# Run tests with coverage
-npm run test:coverage
-```
-
-The `test:report` script provides a comprehensive test report showing detailed information about all tests that were run, including test names, execution time, and pass/fail status.
-
-### Testing Best Practices
-
-When developing and debugging Brainy, follow these testing guidelines:
-
-1. **Use Proper Test Files**: All tests should be written as vitest test files in the `tests/` directory with `.test.ts` or `.spec.ts` extensions.
-
-2. **Avoid Temporary Debug Files**: Do not create temporary debug files like `debug_test.js`, `reproduce_issue.js`, or similar files in the root directory. These files:
-   - Clutter the repository
-   - Are excluded by vitest configuration but remain in the codebase
-   - Often duplicate functionality already covered by proper tests
-
-3. **Debugging Approach**: When debugging issues:
-   - Add temporary test cases to existing test files in the `tests/` directory
-   - Use `it.only()` or `describe.only()` to focus on specific tests during debugging
-   - Remove or convert temporary test cases to permanent tests before committing
-   - Use the existing test setup and utilities in `tests/setup.ts`
-
-4. **Test Organization**: 
-   - Core functionality tests go in `tests/core.test.ts`
-   - Environment-specific tests go in `tests/environment.*.test.ts`
-   - Utility function tests go in `tests/vector-operations.test.ts`
-   - New feature tests should follow the existing naming convention
-
-5. **Cleanup**: Always clean up temporary files before committing. The vitest configuration already excludes `*.js` files in the root directory, but they should be deleted rather than left in the repository.
-
-6. **Test Reporting**: Use the comprehensive test reporting feature when you need detailed information about test execution:
-   - Run `npm run test:report` to get a verbose report of all tests
-   - The report includes test names, execution time, and pass/fail status
-   - This is especially useful for CI/CD pipelines and debugging test failures
-
-### Testing All Environments
-
-Brainy provides a comprehensive test script that verifies the library works correctly in all supported environments (
-browser, Node.js, and CLI):
-
-```bash
-# Test the library in all environments
-npm run test:all
-```
-
-This script:
-
-1. Builds all packages (main, browser, CLI)
-2. Runs Node.js tests (worker tests and unified text encoding test)
-3. Starts a local HTTP server and runs browser tests using Puppeteer (headless browser)
-4. Runs CLI tests by installing the CLI package locally and testing basic commands
-
-The test results are displayed with color-coded output for better readability.
-
-### Testing the CLI Package Locally
-
-Before publishing the CLI package to npm, you can test it locally to ensure it works as expected:
-
-```bash
-# Test the CLI package locally
-npm run test:cli
-```
-
-This script:
-
-1. Builds the main package
-2. Creates a local tarball of the main package
-3. Builds the CLI package
-4. Updates the CLI package to use the local main package
-5. Creates a local tarball of the CLI package
-6. Installs the CLI package globally for testing
-
-After running this script, you can use the CLI commands as if you had installed the package from npm:
-
-```bash
-# Test the CLI
-brainy --version
-brainy init
-brainy add "Test data" '{"noun":"Thing"}'
-brainy search "test"
-```
-
-When you're done testing, you can uninstall the CLI package:
-
-```bash
-npm uninstall -g @soulcraft/brainy-cli
-```
-
-## Publishing
-
-### Publishing the CLI Package
-
-If you need to publish the CLI package to npm, please refer to the [CLI Publishing Guide](docs/publishing-cli.md) for
-detailed instructions.
-
-## Development Usage
-
-```bash
-# Run the CLI directly from the source
-npm run cli help
-
-# Generate a random graph for testing
-npm run cli generate-random-graph --noun-count 20 --verb-count 40
-```
-
-## Node.js 24 Optimizations
-
-Brainy takes advantage of several optimizations available in Node.js 24:
-
-1. **Improved Worker Threads Performance**: The multithreading system has been completely rewritten to leverage Node.js
-   24's enhanced Worker Threads API, resulting in better performance for compute-intensive operations like embedding
-   generation and vector similarity calculations.
-
-2. **Worker Pool Management**: A sophisticated worker pool system reuses worker threads to minimize the overhead of
-   creating and destroying threads, leading to more efficient resource utilization.
-
-3. **Dynamic Module Imports**: Uses the new `node:` protocol prefix for importing core modules, which provides better
-   performance and more reliable module resolution.
-
-4. **ES Modules Optimizations**: Takes advantage of Node.js 24's improved ESM implementation for faster module loading
-   and execution.
-
-5. **Enhanced Error Handling**: Implements more robust error handling patterns available in Node.js 24 for better
-   stability and debugging.
-
-These optimizations are particularly beneficial for:
-
-- Large-scale vector operations
-- Batch processing of embeddings
-- Real-time data processing pipelines
-- High-throughput search operations
-
-## Development Workflow
-
-1. Fork the repository
-2. Create a feature branch
-3. Make your changes
-4. Submit a pull request
-
-## Reporting Issues
-
-We use GitHub issues to track bugs and feature requests. When creating a new issue, please provide detailed information including steps to reproduce, expected behavior, and actual behavior for bugs, or clear use cases and benefits for feature requests.
-
-## Code Style Guidelines
-
-Brainy follows a specific code style to maintain consistency throughout the codebase:
-
-1. **No Semicolons**: All code in the project should avoid using semicolons wherever possible
-2. **Formatting**: The project uses Prettier for code formatting
-3. **Linting**: ESLint is configured with specific rules for the project
-4. **TypeScript Configuration**: Strict type checking enabled with ES2020 target
-5. **Commit Messages**: Use the imperative mood and keep the first line concise
-
-## Badge Maintenance
-
-The README badges are automatically updated during the build process:
-
-1. **npm Version Badge**: The npm version badge is automatically updated to match the version in package.json when:
-    - Running `npm run build` (via the prebuild script)
-    - Running `npm version` commands (patch, minor, major)
-    - Manually running `node scripts/generate-version.js`
-
-This ensures that the badge always reflects the current version in package.json, even before publishing to npm.

DIMENSION_MISMATCH_SUMMARY.md

@@ -1,103 +0,0 @@
-# Dimension Mismatch Issue: Summary and Recommendations
-
-## What Happened
-
-The search functionality in Brainy stopped working because of a dimension mismatch between stored vectors and the expected dimensions in the current version of the codebase:
-
-1. **Previous State**: The system was using vectors with 3 dimensions.
-2. **Current State**: The system now expects 512-dimensional vectors from the Universal Sentence Encoder.
-3. **Code Change**: Recent updates (around July 16, 2025) introduced dimension validation during initialization, which skips vectors with mismatched dimensions.
-4. **Result**: During initialization, vectors with 3 dimensions were skipped, resulting in an empty search index and no search results.
-
-## Root Cause Analysis
-
-The root cause was identified by examining the codebase:
-
-1. In `brainyData.ts`, the `init()` method checks if vector dimensions match the expected dimensions (line 400):
-   ```javascript
-   if (noun.vector.length !== this._dimensions) {
-     console.warn(
-       `Skipping noun ${noun.id} due to dimension mismatch: expected ${this._dimensions}, got ${noun.vector.length}`
-     )
-     // Skip this noun and continue with the next one
-     return;
-   }
-   ```
-
-2. The default dimension is set to 512 in the constructor (line 200):
-   ```javascript
-   this._dimensions = config.dimensions || 512
-   ```
-
-3. The `UniversalSentenceEncoder` class in `embedding.ts` produces 512-dimensional vectors (lines 358-359):
-   ```javascript
-   // Return a zero vector of appropriate dimension (512 is the default for USE)
-   return new Array(512).fill(0)
-   ```
-
-4. Git history shows that on July 16, 2025, a commit was made that added dimension validation:
-   ```
-   Added a `dimensions` property to `BrainyDataConfig` for specifying vector dimensions.
-   Introduced validation for vector dimensions during database creation and insertion to ensure consistency.
-   Enhanced error handling and logging for dimension mismatches.
-   ```
-
-This indicates that the system previously used 3-dimensional vectors, but after the update, it expects 512-dimensional vectors. The existing data was not migrated, causing the search functionality to break.
-
-## Solution Implemented
-
-We created and tested a fix script (`fix-dimension-mismatch.js`) that:
-
-1. Creates a backup of the existing data
-2. Reads all noun files directly from the filesystem
-3. For each noun:
-   - Extracts text from metadata
-   - Deletes the existing noun
-   - Re-adds the noun with the same ID but using the current embedding function
-4. Recreates all verb relationships between the re-embedded nouns
-5. Verifies that search works by performing a test search
-
-The script successfully fixed the issue by re-embedding all data with the correct dimensions, and search functionality was restored.
-
-## Production Recommendations
-
-For production environments, we recommend:
-
-### 1. Use the Enhanced Migration Script
-
-We've created a comprehensive production migration guide (`production-migration-guide.md`) that includes:
-
-- Enhanced backup strategies with metadata
-- Batching for large datasets
-- Robust error handling and recovery
-- Progress monitoring and reporting
-- A parallel database approach for mission-critical systems
-
-### 2. Implement Preventive Measures
-
-To prevent similar issues in the future:
-
-- **Version Tracking**: Add version information to stored vectors
-- **Auto-Migration**: Enhance initialization to automatically re-embed mismatched vectors
-- **Regular Validation**: Implement a database validation process
-- **Documentation**: Document embedding changes in release notes
-
-### 3. Scheduling and Communication
-
-- Schedule the migration during a maintenance window
-- Communicate the change to all stakeholders
-- Have a rollback plan in case of issues
-- Monitor the system after the migration
-
-## Conclusion
-
-The dimension mismatch issue was caused by a change in the embedding function that increased vector dimensions from 3 to 512. The solution is to re-embed all existing data using the current embedding function, which can be done using the provided `fix-dimension-mismatch.js` script with the enhancements suggested for production environments.
-
-By implementing the preventive measures outlined in the production migration guide, you can avoid similar issues in the future and ensure smoother transitions when embedding functions or vector dimensions change.
-
-## Files Created
-
-1. `check-database.js` - Script to verify database status and search functionality
-2. `fix-dimension-mismatch.js` - Script to fix the dimension mismatch issue
-3. `production-migration-guide.md` - Comprehensive guide for production migration
-4. `DIMENSION_MISMATCH_SUMMARY.md` - This summary document

DOCUMENTATION_STANDARDS.md

@@ -1,153 +0,0 @@
-# Documentation Standards for Brainy
-
-<div align="center">
-<img src="./brainy.png" alt="Brainy Logo" width="200"/>
-</div>
-
-This document outlines the documentation standards and conventions for the Brainy project, including markdown file naming conventions and troubleshooting information for common documentation issues.
-
-## Table of Contents
-
-- [Markdown File Naming Conventions](#markdown-file-naming-conventions)
-- [Documentation Troubleshooting](#documentation-troubleshooting)
-
-## Markdown File Naming Conventions
-
-Based on the current project structure, we follow these conventions for markdown files:
-
-### Uppercase Naming
-
-Use uppercase filenames for project-level documentation:
-
-- README.md - Project overview and main documentation
-- CONTRIBUTING.md - Contribution guidelines
-- LICENSE.md - License information
-- CHANGES.md - Changelog
-- CODE_OF_CONDUCT.md - Code of conduct
-- Other project-level documentation files
-
-Examples: `README.md`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`
-
-### Lowercase Naming
-
-Use lowercase filenames for technical documentation and implementation details:
-
-- Technical guides
-- Implementation details
-- Architecture documentation
-- Specific feature documentation
-
-Examples: `scalingStrategy.md`, `statistics.md`
-
-## Rationale
-
-This convention makes it easy to distinguish between:
-
-1. Project-level documentation that applies to the entire project and is relevant to all contributors and users (uppercase)
-2. Technical documentation that focuses on specific implementation details and is primarily relevant to developers working on those features (lowercase)
-
-## Recommendations
-
-1. Continue using uppercase names for project-level documentation files
-2. Continue using lowercase names for technical documentation files
-3. Be consistent within each category
-4. Always use `README.md` (uppercase) for directory-level documentation
-
-## Examples
-
-### Project-Level Documentation (Uppercase)
-
-- README.md
-- CONTRIBUTING.md
-- LICENSE.md
-- CHANGES.md
-- CODE_OF_CONDUCT.md
-- DEVELOPERS.md
-- STORAGE_TESTING.md
-- THREADING.md
-
-### Technical Documentation (Lowercase)
-
-- scalingStrategy.md
-- statistics.md
-- architecture.md
-- implementation-details.md
-
-By following these conventions, we maintain consistency and make it easier for contributors to find the right documentation.
-
-## Documentation Troubleshooting
-
-This section covers common documentation-related issues and their solutions.
-
-### Fix for "process.memoryUsage is not a function" Error in Vitest
-
-#### Issue
-During test runs with Vitest, the following error was occurring:
-
-```
-TypeError: process.memoryUsage is not a function
- ❯ VitestTestRunner.onAfterRunSuite node_modules/vitest/dist/runners.js:150:95
-```
-
-This error was happening because Vitest was trying to use `process.memoryUsage()` to log heap usage statistics, but this function was not available in the current environment.
-
-#### Solution
-The issue was fixed by disabling the heap usage logging in the Vitest configuration:
-
-In `vitest.config.ts`, changed:
-```typescript
-// Show test statistics
-logHeapUsage: true,
-```
-
-To:
-```typescript
-// Show test statistics
-logHeapUsage: false,
-```
-
-#### Explanation
-The `logHeapUsage` option in Vitest attempts to use Node.js's `process.memoryUsage()` function to track and report memory usage during test runs. However, this function might not be available in all environments, particularly in certain browser-like environments or when using specific Node.js versions or configurations.
-
-By setting `logHeapUsage: false`, we prevent Vitest from attempting to call this function, which resolves the error while still allowing tests to run successfully.
-
-#### Verification
-After making this change, the tests run without any unhandled errors, confirming that the issue has been resolved.
-
-### Common Documentation Issues and Solutions
-
-#### Issue: Inconsistent Markdown Formatting
-
-**Symptoms**: Inconsistent heading levels, list formatting, or code block syntax across documentation files.
-
-**Solution**: 
-- Use a markdown linter to enforce consistent formatting
-- Follow the project's markdown style guide
-- Use the same heading structure across similar documents
-
-#### Issue: Broken Links in Documentation
-
-**Symptoms**: Links to other documentation files or sections within files don't work.
-
-**Solution**:
-- Use relative links for references to other files in the repository
-- Use anchor links for references to sections within the same file
-- Regularly check for broken links, especially after moving or renaming files
-
-#### Issue: Outdated Documentation
-
-**Symptoms**: Documentation describes features or APIs that have changed or been removed.
-
-**Solution**:
-- Update documentation as part of the same PR that changes the code
-- Add a "Last Updated" date to documentation files
-- Regularly review and update documentation
-
-#### Issue: Missing Documentation
-
-**Symptoms**: Features or APIs lack documentation, making them difficult to use.
-
-**Solution**:
-- Require documentation for new features as part of the PR review process
-- Create documentation templates for common types of documentation
-- Identify and prioritize documentation gaps

Dockerfile

@@ -0,0 +1,72 @@
+# Multi-stage Dockerfile for Brainy
+# Optimized for production deployment with minimal image size
+
+# Stage 1: Build stage
+FROM node:22-alpine AS builder
+
+# Install build dependencies
+RUN apk add --no-cache python3 make g++
+
+# Set working directory
+WORKDIR /app
+
+# Copy package files
+COPY package*.json ./
+
+# Install all dependencies (including dev dependencies for building)
+RUN npm ci
+
+# Copy source code
+COPY . .
+
+# Build the TypeScript code
+RUN npm run build
+
+# Remove dev dependencies and only keep production ones
+RUN npm prune --production
+
+# Stage 2: Production stage
+FROM node:22-alpine
+
+# Install production dependencies only
+RUN apk add --no-cache tini
+
+# Create non-root user for security
+RUN addgroup -g 1001 -S nodejs && \
+    adduser -S nodejs -u 1001
+
+# Set working directory
+WORKDIR /app
+
+# Copy package files
+COPY package*.json ./
+
+# Copy built application from builder stage
+COPY --from=builder --chown=nodejs:nodejs /app/node_modules ./node_modules
+COPY --from=builder --chown=nodejs:nodejs /app/dist ./dist
+
+# Copy necessary static files
+COPY --chown=nodejs:nodejs README.md LICENSE ./
+
+# Create data directory for file-based storage
+RUN mkdir -p /app/data && chown -R nodejs:nodejs /app/data
+
+# Switch to non-root user
+USER nodejs
+
+# Expose default port (can be overridden)
+EXPOSE 3000
+
+# Set environment variables for production
+ENV NODE_ENV=production
+ENV BRAINY_STORAGE_PATH=/app/data
+
+# Health check endpoint
+HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
+  CMD node -e "require('http').get('http://localhost:3000/health', (r) => r.statusCode === 200 ? process.exit(0) : process.exit(1))"
+
+# Use tini to handle signals properly
+ENTRYPOINT ["/sbin/tini", "--"]
+
+# Default command (can be overridden)
+CMD ["node", "dist/index.js"]

EXPECTED_TEST_MESSAGES.md

@@ -1,35 +0,0 @@
-# Expected Messages During Vitest Execution
-
-This document explains the various messages and errors that appear during test execution and why they are expected.
-
-## Fixed Issues
-
-### Duplicate Summary Output
-- **Issue**: Previously, test summaries were appearing twice at the end of test runs
-- **Fix**: Removed the verbose reporter from the configuration, keeping only the default and JSON reporters
-- **Status**: Resolved
-
-## Expected Error Messages
-
-The following error messages appear during test runs and are expected as part of the test suite:
-
-### S3 Storage Tests
-- **Error**: `[MOCK S3] Error processing command: Error: NoSuchKey: The specified key does not exist.`
-- **Source**: `tests/s3-storage.test.ts`
-- **Explanation**: This error is expected and is part of the test for the S3 storage adapter. The test intentionally deletes a noun and then tries to retrieve it to verify it was properly deleted.
-
-### Dimension Mismatch Errors
-- **Error**: `Failed to add vector: Error: Vector dimension mismatch: expected 512, got X`
-- **Source**: `tests/dimension-standardization.test.ts` and `tests/core.test.ts`
-- **Explanation**: These tests specifically verify that the system correctly rejects vectors with incorrect dimensions. The error messages confirm that the validation is working as expected.
-
-### API Integration Test Failure
-- **Error**: `expected 500 to be 200 // Object.is equality`
-- **Source**: `tests/api-integration.test.ts`
-- **Explanation**: This appears to be an actual test failure that should be investigated separately. The test expects a 200 status code but is receiving a 500 error.
-
-## Conclusion
-
-Most of the error messages seen during test execution are expected and are part of testing error handling paths. These messages confirm that the system is correctly handling error conditions as designed.
-
-The only unexpected issue is the API integration test failure, which should be investigated as a separate issue.

LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2023 Soulcraft Research
+Copyright (c) 2024 Brainy Data Contributors
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
@@ -18,4 +18,4 @@ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+SOFTWARE.

MARKDOWN_CONVENTIONS.md

@@ -1,67 +0,0 @@
-# Markdown File Naming Conventions
-
-This document outlines the naming conventions for markdown (.md) files in the Brainy project.
-
-## Naming Patterns
-
-Based on the current project structure, we follow these conventions for markdown files:
-
-### Uppercase Naming
-
-Use uppercase filenames for project-level documentation:
-
-- README.md - Project overview and main documentation
-- CONTRIBUTING.md - Contribution guidelines
-- LICENSE.md - License information
-- CHANGES.md - Changelog
-- CODE_OF_CONDUCT.md - Code of conduct
-- Other project-level documentation files
-
-Examples: `README.md`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`
-
-### Lowercase Naming
-
-Use lowercase filenames for technical documentation and implementation details:
-
-- Technical guides
-- Implementation details
-- Architecture documentation
-- Specific feature documentation
-
-Examples: `scalingStrategy.md`, `statistics.md`
-
-## Rationale
-
-This convention makes it easy to distinguish between:
-
-1. Project-level documentation that applies to the entire project and is relevant to all contributors and users (uppercase)
-2. Technical documentation that focuses on specific implementation details and is primarily relevant to developers working on those features (lowercase)
-
-## Recommendations
-
-1. Continue using uppercase names for project-level documentation files
-2. Continue using lowercase names for technical documentation files
-3. Be consistent within each category
-4. Always use `README.md` (uppercase) for directory-level documentation
-
-## Examples
-
-### Project-Level Documentation (Uppercase)
-
-- README.md
-- CONTRIBUTING.md
-- LICENSE.md
-- CHANGES.md
-- CODE_OF_CONDUCT.md
-- DEVELOPERS.md
-- STORAGE_TESTING.md
-- THREADING.md
-
-### Technical Documentation (Lowercase)
-
-- scalingStrategy.md
-- statistics.md
-- architecture.md
-- implementation-details.md
-
-By following these conventions, we maintain consistency and make it easier for contributors to find the right documentation.

METADATA_HANDLING.md

@@ -1,60 +0,0 @@
-# Metadata Handling in Brainy
-
-## Issue Description
-
-Two edge case tests were failing:
-
-1. **Empty metadata test**: When adding an item with empty metadata (`{}`), the metadata returned by `get()` included an ID field, causing the test to fail.
-2. **Large metadata test**: When adding an item with exactly 100 metadata keys, the metadata returned by `get()` had 101 keys (including the ID), causing the test to fail.
-
-## Root Cause
-
-The issue is in the `add()` method of the `BrainyData` class. When saving metadata, the method always adds the item's ID to the metadata object:
-
-```javascript
-metadataToSave = {...metadata, id}
-```
-
-This behavior causes two problems:
-1. Empty metadata (`{}`) becomes `{ id: "some-uuid" }`, which is no longer empty
-2. Metadata with exactly 100 keys becomes 101 keys when the ID is added
-
-## Solution Approach
-
-We attempted several approaches to fix the issue:
-
-1. **Modify the `add()` method**: We tried to skip saving metadata for empty objects and not adding the ID to metadata with exactly 100 keys. However, this didn't work as expected, possibly due to how the storage layer handles metadata.
-
-2. **Modify the `get()` method**: We tried to handle special cases in the `get()` method by returning an empty object when metadata only has an ID, and removing the ID when metadata has more than 100 keys. This also didn't work as expected.
-
-3. **Workaround in tests**: As a temporary solution, we modified the tests to manually remove the ID from the metadata before the assertions:
-
-```javascript
-// For empty metadata test
-if (item.metadata && typeof item.metadata === 'object') {
-  const { id: _, ...rest } = item.metadata
-  item.metadata = rest
-}
-
-// For large metadata test
-if (item.metadata && typeof item.metadata === 'object' && 'id' in item.metadata) {
-  const { id: _, ...rest } = item.metadata
-  item.metadata = rest
-}
-```
-
-## Future Improvements
-
-For a more permanent solution, consider one of the following approaches:
-
-1. **Modify the storage layer**: Update the storage adapters to handle metadata differently, ensuring that empty metadata remains empty and large metadata doesn't exceed the expected size.
-
-2. **Add configuration option**: Add a configuration option to control whether the ID is added to metadata, allowing users to disable this behavior when needed.
-
-3. **Implement metadata filtering**: Add a method to filter metadata before returning it, allowing users to exclude certain fields like the ID.
-
-4. **Update tests expectations**: If adding the ID to metadata is the intended behavior, update the tests to expect this behavior instead of trying to work around it.
-
-## Conclusion
-
-The current workaround in the tests allows them to pass, but a more permanent solution should be implemented to handle metadata consistently throughout the library. The decision on which approach to take depends on the intended behavior of the library and how metadata should be handled in different scenarios.

PRETTY_TEST_REPORTER.md

@@ -1,73 +0,0 @@
-# Pretty Test Reporter for Brainy
-
-This document describes the visually enhanced test reporter added to the Brainy project.
-
-## Overview
-
-The Pretty Test Reporter provides a visually appealing summary of test results with colors, symbols, and formatted output. It enhances the standard Vitest output with a clear, easy-to-read summary at the end of test runs.
-
-## Features
-
-- 🎨 **Colorful Output**: Uses colors to distinguish between passed, failed, and skipped tests
-- 📊 **Tabular Format**: Displays test results in a clean, tabular format
-- 📝 **Detailed Summary**: Shows overall test statistics and file-by-file breakdown
-- ❌ **Error Reporting**: Clearly lists any failed tests with their error messages
-- ⏱️ **Timing Information**: Displays test duration in a human-readable format
-
-## Usage
-
-To run tests with the pretty reporter, use the following npm script:
-
-```bash
-npm run test:report:pretty
-```
-
-You can also specify specific test files:
-
-```bash
-npm run test:report:pretty -- tests/core.test.ts
-```
-
-## Example Output
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-📊 TEST SUMMARY REPORT
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Test Run Completed in: 7.9s
-Date: 7/28/2025, 11:22:54 AM
-Total Test Files: 1
-Total Tests: 19
-
-Results:
-  ✓ Passed: 19
-  ✗ Failed: 0
-  ○ Skipped: 0
-
-Test Files:
-┌──────────────────────────────────────────────────┬──────────┬──────────┬──────────┐
-│ File                                              │ Passed    │ Failed    │ Skipped   │
-├──────────────────────────────────────────────────┼──────────┼──────────┼──────────┤
-│ core.test.ts                                      │ 19        │ 0         │ 0         │
-└──────────────────────────────────────────────────┴──────────┴──────────┴──────────┘
-
- PASSED  All tests passed successfully!
-```
-
-## Implementation Details
-
-The pretty reporter is implemented as a custom Vitest reporter in `src/testing/prettySummaryReporter.ts`. It:
-
-1. Collects test information during the test run
-2. Tracks passed, failed, and skipped tests
-3. Organizes results by test file
-4. Generates a formatted summary at the end of the test run
-
-## Configuration
-
-The reporter is configured in `vitest.config.ts` and works alongside the default Vitest reporter and JSON reporter. This provides both the standard output during test execution and the enhanced summary at the end.
-
-## Customization
-
-If you need to modify the reporter's appearance or behavior, you can edit the `prettySummaryReporter.ts` file. The main visual elements are in the `printSummary` method.

REALTIME_UPDATES.md

@@ -1,182 +0,0 @@
-# Real-time Updates in Brainy
-
-This document explains the real-time update features in Brainy, which ensure that the in-memory index and statistics are always up-to-date with the latest data in storage.
-
-## Overview
-
-When running Brainy inside a web service with data being constantly added in a stream (using S3 or any other storage option), the new data needs to be searchable in real-time. The real-time update feature periodically checks for new data in storage and updates the in-memory index and statistics accordingly.
-
-## Configuration
-
-Real-time updates can be configured when creating a BrainyData instance:
-
-```typescript
-import { BrainyData } from '@soulcraft/brainy'
-
-const db = new BrainyData({
-  // ... other configuration options ...
-  
-  // Real-time update configuration
-  realtimeUpdates: {
-    // Whether to enable automatic updates (default: false)
-    enabled: true,
-    
-    // The interval in milliseconds at which to check for updates (default: 30000 - 30 seconds)
-    interval: 10000, // 10 seconds
-    
-    // Whether to update statistics when checking for updates (default: true)
-    updateStatistics: true,
-    
-    // Whether to update the index when checking for updates (default: true)
-    updateIndex: true
-  }
-})
-```
-
-## Runtime Control
-
-Real-time updates can also be controlled at runtime:
-
-### Enable Real-time Updates
-
-```typescript
-// Enable with default configuration
-db.enableRealtimeUpdates()
-
-// Enable with custom configuration
-db.enableRealtimeUpdates({
-  interval: 5000, // 5 seconds
-  updateStatistics: true,
-  updateIndex: true
-})
-```
-
-### Disable Real-time Updates
-
-```typescript
-db.disableRealtimeUpdates()
-```
-
-### Get Current Configuration
-
-```typescript
-const config = db.getRealtimeUpdateConfig()
-console.log(`Real-time updates enabled: ${config.enabled}`)
-console.log(`Update interval: ${config.interval}ms`)
-```
-
-### Manual Update Check
-
-You can also manually check for updates at any time, regardless of whether automatic updates are enabled:
-
-```typescript
-await db.checkForUpdatesNow()
-```
-
-## How It Works
-
-When real-time updates are enabled, Brainy will:
-
-1. Periodically check for new data in storage at the specified interval.
-2. If new data is found, update the in-memory index with the new data.
-3. Update the statistics to reflect the latest data.
-
-This ensures that search operations and statistics always reflect the latest data, even when data is being added by external processes.
-
-### Incremental Updates
-
-The real-time update mechanism is designed to be efficient and only processes new data:
-
-- **Incremental Indexing**: Brainy only adds new items to the index that aren't already there, rather than reloading the entire index. It compares the IDs of items in storage with those already in the index to identify only the new items that need to be added.
-
-- **Efficient Statistics Updates**: Statistics are updated incrementally as well, with changes being batched for performance.
-
-### Handling Large Indices
-
-Brainy is designed to handle indices that are too large to fit entirely in memory:
-
-- **Optimized HNSW Implementation**: Brainy uses the `HNSWIndexOptimized` class which supports large datasets through:
-  - **Product Quantization**: Compresses vectors to reduce memory usage while maintaining search quality
-  - **Disk-Based Storage**: Can offload parts of the index to disk when memory is constrained
-
-- **Memory Management**: When the index grows too large for available memory:
-  1. The most frequently accessed items are kept in memory for fast access
-  2. Less frequently accessed items may be stored on disk and loaded when needed
-  3. The system automatically balances memory usage based on access patterns
-
-- **Configurable Trade-offs**: You can configure the balance between memory usage and performance through the HNSW configuration options when creating the database.
-
-## Best Practices
-
-- For high-volume data streams, set a reasonable update interval to balance real-time updates with performance.
-- If you only need occasional updates, disable automatic updates and use `checkForUpdatesNow()` when needed.
-- For web services with multiple instances, each instance will maintain its own in-memory index and statistics.
-
-## Compatibility
-
-Real-time updates work with all storage options supported by Brainy, including:
-
-- File system storage
-- Memory storage
-- S3 storage
-- Custom storage adapters
-
-## Example: Web Service with S3 Storage
-
-```typescript
-import { BrainyData } from '@soulcraft/brainy'
-import express from 'express'
-
-const app = express()
-
-// Create a BrainyData instance with S3 storage and real-time updates
-const db = new BrainyData({
-  storage: {
-    s3Storage: {
-      bucketName: 'my-brainy-bucket',
-      accessKeyId: process.env.AWS_ACCESS_KEY_ID,
-      secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
-      region: 'us-west-2'
-    }
-  },
-  realtimeUpdates: {
-    enabled: true,
-    interval: 30000 // 30 seconds
-  }
-})
-
-// Initialize the database
-await db.init()
-
-// API endpoint to search
-app.get('/search', async (req, res) => {
-  const { query, limit } = req.query
-  const results = await db.searchText(query, parseInt(limit) || 10)
-  res.json(results)
-})
-
-// API endpoint to get statistics
-app.get('/stats', async (req, res) => {
-  const stats = await db.getStatistics()
-  res.json(stats)
-})
-
-// API endpoint to manually check for updates
-app.post('/update', async (req, res) => {
-  await db.checkForUpdatesNow()
-  res.json({ success: true })
-})
-
-// Start the server
-app.listen(3000, () => {
-  console.log('Server running on port 3000')
-})
-
-// Graceful shutdown
-process.on('SIGINT', async () => {
-  await db.shutDown()
-  process.exit(0)
-})
-```
-
-In this example, the BrainyData instance will automatically check for new data in the S3 bucket every 30 seconds, ensuring that search results and statistics are always up-to-date.

SECURITY.md

@@ -0,0 +1,36 @@
+# Security Policy
+
+## Reporting a vulnerability
+
+Email **security@soulcraft.com**. That's the one door for security reports
+across the company, and it works the same way for Brainy: every report is
+read by a human, you'll get a private receipt, and we'll work with you on
+coordinated disclosure — please don't open a public issue for anything
+that isn't already public.
+
+Include what you'd want if you were on the other end: affected version,
+how to reproduce, and what you think the impact is. If you have a patch or
+a suggested fix, send it along — it's welcome but not required.
+
+There is no bounty program today. We're saying that plainly so you know
+what to expect going in.
+
+## Response time
+
+We respond as fast as truth allows. That means: no fixed SLA, no promise of
+a reply within a specific number of hours — but a real report from a real
+person gets read promptly and taken seriously. If you haven't heard anything
+in a reasonable stretch, a follow-up email is completely fine.
+
+## Supported versions
+
+The latest `8.x` minor release line receives security fixes. If you're
+running an older major version, please upgrade before reporting — we can't
+commit to backporting fixes to unsupported lines.
+
+## Scope
+
+This policy covers the `@soulcraft/brainy` package itself — the code in
+this repository. If you're evaluating a deployment that also uses
+`@soulcraft/cor`, report issues in that package the same way, to the same
+address; we'll route internally.

STATISTICS.md

@@ -1,364 +0,0 @@
-# Brainy Statistics System
-
-<div align="center">
-<img src="./brainy.png" alt="Brainy Logo" width="200"/>
-</div>
-
-This document provides a comprehensive overview of the statistics system in Brainy, including its implementation, scalability considerations, and recent improvements.
-
-## Table of Contents
-
-- [Overview](#overview)
-- [What is Tracked](#what-is-tracked)
-- [How Statistics Are Collected](#how-statistics-are-collected)
-- [Retrieving Statistics](#retrieving-statistics)
-- [Implementation Details](#implementation-details)
-- [Scalability Improvements](#scalability-improvements)
-- [Statistics Flush Solution](#statistics-flush-solution)
-- [Best Practices](#best-practices)
-- [Use Cases](#use-cases)
-- [Consistency of Statistics Tracking](#consistency-of-statistics-tracking)
-
-## Overview
-
-Brainy includes a built-in statistics system that tracks various metrics about your data as it's added to the database. The statistics are stored persistently and updated in real-time, providing an efficient way to monitor the state of your database without having to recalculate metrics on each request.
-
-Key features of the statistics system:
-
-- **Persistent Tracking**: Statistics are stored persistently and updated as data is added or removed
-- **Service-Based Tracking**: Data is tracked by the service that inserted it
-- **Filtering Capabilities**: Statistics can be filtered by service
-- **Comprehensive Metrics**: Tracks nouns, verbs, metadata, and HNSW index size
-
-## What is Tracked
-
-The statistics system tracks the following metrics:
-
-1. **Noun Count**: The number of nouns (vector data points) in the database, tracked by service
-2. **Verb Count**: The number of verbs (relationships between nouns) in the database, tracked by service
-3. **Metadata Count**: The number of metadata entries in the database, tracked by service
-4. **HNSW Index Size**: The total size of the HNSW index used for vector search
-
-## How Statistics Are Collected
-
-Statistics are collected automatically as data is added to or removed from the database:
-
-- When a noun is added using `add()`, the noun count for the specified service is incremented
-- When a verb is added using `addVerb()` or `relate()`, the verb count for the specified service is incremented
-- When metadata is added along with a noun, the metadata count for the specified service is incremented
-- The HNSW index size is updated whenever nouns are added or removed
-
-Each operation includes a `service` parameter that identifies which service is adding the data. If not specified, the service defaults to "default".
-
-```typescript
-// Adding data with a specific service
-await brainyDb.add(vector, metadata, {service: "my-service"});
-
-// Adding a verb with a specific service
-await brainyDb.addVerb(sourceId, targetId, vector, {
-    type: "related_to",
-    service: "my-service"
-});
-```
-
-## Retrieving Statistics
-
-You can retrieve statistics using the `getStatistics()` method on a BrainyData instance:
-
-```typescript
-// Get all statistics
-const stats = await brainyDb.getStatistics();
-console.log(stats);
-```
-
-The result will include counts for all metrics and a breakdown by service:
-
-```javascript
-{
-    nounCount: 150,
-    verbCount: 75,
-    metadataCount: 150,
-    hnswIndexSize: 150,
-    serviceBreakdown: {
-        "default": {
-            nounCount: 100,
-            verbCount: 50,
-            metadataCount: 100
-        },
-        "my-service": {
-            nounCount: 50,
-            verbCount: 25,
-            metadataCount: 50
-        }
-    }
-}
-```
-
-### Filtering by Service
-
-You can filter statistics by service using the `service` option:
-
-```typescript
-// Get statistics for a specific service
-const serviceStats = await brainyDb.getStatistics({
-    service: "my-service"
-});
-console.log(serviceStats);
-```
-
-You can also filter by multiple services:
-
-```typescript
-// Get statistics for multiple services
-const multiServiceStats = await brainyDb.getStatistics({
-    service: ["service1", "service2"]
-});
-console.log(multiServiceStats);
-```
-
-## Implementation Details
-
-The statistics system is implemented using the following components:
-
-1. **StatisticsData Interface**: Defines the structure of statistics data
-2. **BaseStorageAdapter**: Provides common functionality for statistics tracking
-3. **Storage Adapters**: Implement persistence for statistics data
-4. **BrainyData.getStatistics**: Provides the API for retrieving statistics
-
-### Storage Adapter Implementation
-
-All storage adapters must implement the following statistics-related methods:
-
-1. `saveStatistics(statistics: StatisticsData): Promise<void>`
-2. `getStatistics(): Promise<StatisticsData | null>`
-3. `incrementStatistic(type: 'noun' | 'verb' | 'metadata', service: string, amount?: number): Promise<void>`
-4. `decrementStatistic(type: 'noun' | 'verb' | 'metadata', service: string, amount?: number): Promise<void>`
-5. `updateHnswIndexSize(size: number): Promise<void>`
-
-The `BaseStorageAdapter` class provides implementations for these methods, but relies on two abstract methods that must be implemented by subclasses:
-
-1. `protected abstract saveStatisticsData(statistics: StatisticsData): Promise<void>`
-2. `protected abstract getStatisticsData(): Promise<StatisticsData | null>`
-
-## Scalability Improvements
-
-To address scalability issues with millions of database entries, the following improvements have been implemented across all storage adapters:
-
-1. **Local Caching**: Statistics are cached in memory to reduce storage API calls
-2. **Batched Updates**: Updates are batched and flushed periodically to reduce API calls
-3. **Time-based Partitioning**: Statistics are stored in daily files to avoid rate limits on a single object
-4. **Adaptive Flush Timing**: The system adjusts the flush frequency based on recent activity
-5. **Optimistic Concurrency Control**: Prevents race conditions when multiple processes update statistics
-6. **Periodic Aggregation**: For high-volume scenarios, statistics are periodically recalculated from scratch
-7. **Distributed Locking**: For multi-instance deployments, distributed locking prevents concurrent updates
-
-### Time-based Partitioning Implementation
-
-Statistics are now stored in daily files with keys following the pattern:
-`statistics_YYYYMMDD.json` (e.g., `statistics_20250724.json` or for S3 storage: `brainy/index/statistics_20250724.json`). This approach offers several benefits:
-
-1. **Avoids Rate Limiting**: By distributing writes across different objects, we avoid hitting rate limits
-2. **Historical Data**: Maintains a historical record of statistics by day
-3. **Reduced Contention**: Multiple processes can update statistics without conflicting
-4. **Backward Compatibility**: The system still checks the legacy location for older data
-
-### Batched Updates Implementation
-
-Statistics updates are now batched and flushed to storage periodically:
-
-1. **In-memory Accumulation**: Changes are accumulated in memory
-2. **Timed Flushes**: Data is flushed to storage on a schedule (5-30 seconds)
-3. **Adaptive Timing**: Flush frequency adjusts based on recent activity
-4. **Error Resilience**: Failed flushes are retried automatically
-5. **Legacy Updates**: The legacy statistics file is updated less frequently (10% of flushes)
-
-### Implementation Across Storage Adapters
-
-These optimizations are now implemented in all storage adapters:
-
-1. **BaseStorageAdapter**: Provides the core implementation of caching and batched updates
-2. **S3CompatibleStorage**: Implements time-based partitioning and fallback mechanisms for cloud storage
-3. **FileSystemStorage**: Implements time-based partitioning and fallback mechanisms for file system storage
-4. **OPFSStorage**: Implements time-based partitioning and fallback mechanisms for browser's Origin Private File System
-5. **MemoryStorage**: Leverages the caching and batching optimizations from BaseStorageAdapter
-
-## Statistics Flush Solution
-
-When inserting lots of data into Brainy, the statistics might not immediately reflect changes due to the batch update mechanism. This section explains the solution to ensure statistics are properly flushed.
-
-### Issue Description
-
-The Brainy database uses a batch update mechanism for statistics to optimize performance. When data is inserted, statistics are updated in memory and a batch update is scheduled to flush the statistics to storage. However, this batch update might be delayed by up to 30 seconds (as defined by `MAX_FLUSH_DELAY_MS` in `baseStorageAdapter.ts`).
-
-If the user checks statistics shortly after inserting data, or if the database is shut down before the batch update occurs, the statistics might not reflect the recent changes.
-
-### Solution
-
-The solution is to provide a way to force an immediate flush of statistics to storage, and to ensure that statistics are flushed before the database is shut down. The following changes were made:
-
-1. Added a new method `flushStatisticsToStorage()` to the `StorageAdapter` interface in `coreTypes.ts`:
-   ```typescript
-   /**
-    * Force an immediate flush of statistics to storage
-    * This ensures that any pending statistics updates are written to persistent storage
-    */
-   flushStatisticsToStorage(): Promise<void>
-   ```
-
-2. Implemented this method in the `BaseStorageAdapter` class in `baseStorageAdapter.ts`:
-   ```typescript
-   /**
-    * Force an immediate flush of statistics to storage
-    * This ensures that any pending statistics updates are written to persistent storage
-    */
-   async flushStatisticsToStorage(): Promise<void> {
-     // If there are no statistics in cache or they haven't been modified, nothing to flush
-     if (!this.statisticsCache || !this.statisticsModified) {
-       return
-     }
-
-     // Call the protected flushStatistics method to immediately write to storage
-     await this.flushStatistics()
-   }
-   ```
-
-3. Added a public method `flushStatistics()` to the `BrainyData` class in `brainyData.ts`:
-   ```typescript
-   /**
-    * Force an immediate flush of statistics to storage
-    * This ensures that any pending statistics updates are written to persistent storage
-    * @returns Promise that resolves when the statistics have been flushed
-    */
-   public async flushStatistics(): Promise<void> {
-     await this.ensureInitialized()
-
-     if (!this.storage) {
-       throw new Error('Storage not initialized')
-     }
-
-     // Call the flushStatisticsToStorage method on the storage adapter
-     await this.storage.flushStatisticsToStorage()
-   }
-   ```
-
-4. Modified the `shutDown()` method in `BrainyData` to flush statistics before shutting down:
-   ```typescript
-   /**
-    * Shut down the database and clean up resources
-    * This should be called when the database is no longer needed
-    */
-   public async shutDown(): Promise<void> {
-     try {
-       // Flush statistics to ensure they're saved before shutting down
-       if (this.storage && this.isInitialized) {
-         try {
-           await this.flushStatistics()
-         } catch (statsError) {
-           console.warn('Failed to flush statistics during shutdown:', statsError)
-           // Continue with shutdown even if statistics flush fails
-         }
-       }
-
-       // Rest of the shutdown process...
-     } catch (error) {
-       console.error('Failed to shut down BrainyData:', error)
-       throw new Error(`Failed to shut down BrainyData: ${error}`)
-     }
-   }
-   ```
-
-### Usage
-
-To ensure statistics are up-to-date after inserting data, you can now call the `flushStatistics()` method on the `BrainyData` instance:
-
-```typescript
-// Insert data
-await brainyDb.add(vectorOrData, metadata)
-
-// Force a flush of statistics to ensure they're up-to-date
-await brainyDb.flushStatistics()
-
-// Get statistics
-const stats = await brainyDb.getStatistics()
-```
-
-Statistics will also be automatically flushed when the database is shut down, ensuring that no statistics updates are lost.
-
-## Best Practices
-
-1. **Always Specify a Service**: When adding data, always specify a service name to properly track where data is coming from
-2. **Use Meaningful Service Names**: Choose service names that clearly identify the source of the data
-3. **Monitor Growth**: Regularly check statistics to monitor database growth and identify potential issues
-4. **Filter When Needed**: Use service filtering to focus on specific parts of your data
-5. **Consider Scalability**: For high-volume scenarios, implement the scalability improvements described above
-6. **Flush When Needed**: Call `flushStatistics()` after batch operations to ensure statistics are up-to-date
-
-## Use Cases
-
-### Monitoring Database Growth
-
-You can use statistics to monitor how your database grows over time:
-
-```typescript
-// Track database growth
-async function monitorGrowth() {
-    const initialStats = await brainyDb.getStatistics();
-    console.log("Initial size:", initialStats.nounCount);
-
-    // Check again after some time
-    setTimeout(async () => {
-        const currentStats = await brainyDb.getStatistics();
-        console.log("Current size:", currentStats.nounCount);
-        console.log("Growth:", currentStats.nounCount - initialStats.nounCount);
-    }, 3600000); // Check after an hour
-}
-```
-
-### Analyzing Service Usage
-
-You can analyze which services are adding the most data:
-
-```typescript
-// Analyze service usage
-async function analyzeServiceUsage() {
-    const stats = await brainyDb.getStatistics();
-
-    // Sort services by noun count
-    const servicesByUsage = Object.entries(stats.serviceBreakdown)
-        .sort((a, b) => b[1].nounCount - a[1].nounCount);
-
-    console.log("Services by usage:");
-    servicesByUsage.forEach(([service, counts]) => {
-        console.log(`${service}: ${counts.nounCount} nouns, ${counts.verbCount} verbs`);
-    });
-}
-```
-
-### Cleaning Up Service Data
-
-You can use statistics to identify services whose data you might want to clean up:
-
-```typescript
-// Identify services with minimal data
-async function identifyInactiveServices() {
-    const stats = await brainyDb.getStatistics();
-
-    const inactiveServices = Object.entries(stats.serviceBreakdown)
-        .filter(([_, counts]) => counts.nounCount < 10);
-
-    console.log("Inactive services:", inactiveServices.map(([service]) => service));
-}
-```
-
-## Consistency of Statistics Tracking
-
-The statistics system consistently tracks:
-
-1. **Total counts**: Overall counts of nouns, verbs, metadata, and index size
-2. **Per-service breakdown**: All counts are tracked by the service that inserted the data
-3. **Real-time updates**: Statistics are updated in real-time as data is added or removed
-4. **Persistent storage**: Statistics are stored persistently and survive database restarts
-
-## Conclusion
-
-The statistics system in Brainy provides valuable insights into your data and how it's being used. By tracking metrics by service, you can better understand how your application is using Brainy and make informed decisions about data management. The system is designed to be efficient and scalable, with minimal overhead for tracking statistics as data is added or removed.

STORAGE_CONCURRENCY_ANALYSIS.md

@@ -1,87 +0,0 @@
-# Storage Adapter Concurrency Analysis
-
-## Overview
-This document analyzes the concurrency requirements for each storage adapter in Brainy and determines which concurrency improvements from the main CONCURRENCY_ANALYSIS.md are applicable to each storage type.
-
-## Storage Adapter Analysis
-
-### 1. S3CompatibleStorage ✅ FULLY IMPLEMENTED
-**Concurrency Risk Level: HIGH**
-- **Multi-instance deployment**: Multiple web services accessing shared S3 storage
-- **Distributed coordination needed**: Services can run on different servers
-- **High throughput scenarios**: Performance critical for large-scale deployments
-
-**Implemented Improvements:**
-- ✅ Distributed locking for statistics updates
-- ✅ Change log mechanism for efficient index synchronization
-- ✅ Thread-safe memory usage tracking (in HNSWIndexOptimized)
-- ✅ Atomic statistics updates with merge strategy
-- ✅ Lock cleanup and expiration handling
-
-### 2. FileSystemStorage ✅ IMPLEMENTED
-**Concurrency Risk Level: MEDIUM**
-- **Multi-process scenarios**: Multiple Node.js processes could access same filesystem
-- **File system locking**: OS provides some protection but not application-level coordination
-- **Local deployment**: Typically single-server scenarios
-
-**Implemented Improvements:**
-- ✅ File-based locking for statistics updates with lock files and expiration
-- ✅ Statistics merging to prevent data loss during concurrent updates
-- ✅ Lock cleanup and expiration handling
-- ✅ Graceful fallback when lock acquisition fails
-
-### 3. OPFSStorage (Origin Private File System) ✅ IMPLEMENTED
-**Concurrency Risk Level: LOW-MEDIUM**
-- **Browser context**: Runs in browser environment
-- **Multi-tab scenarios**: Multiple tabs could access same OPFS storage
-- **Web Worker scenarios**: Could have concurrency with web workers
-- **Origin isolation**: No cross-origin access concerns
-
-**Implemented Improvements:**
-- ✅ Browser-based locking using localStorage for multi-tab coordination
-- ✅ Statistics merging to prevent data loss during concurrent updates
-- ✅ Lock cleanup and expiration handling
-- ✅ Graceful fallback when localStorage is not available
-
-### 4. MemoryStorage
-**Concurrency Risk Level: VERY LOW**
-- **Single process**: Data exists only in memory of one process
-- **JavaScript single-threaded**: No true concurrency in main thread
-- **No persistence**: Data lost on restart, no cross-instance issues
-- **Web Worker edge case**: Minimal risk if shared between workers
-
-**Recommended Improvements:**
-- **None required**: Concurrency risks are minimal
-- **Optional**: Simple mutex for web worker scenarios (very rare use case)
-
-## Implementation Priority
-
-### High Priority ✅ COMPLETE
-1. **S3CompatibleStorage**: ✅ All concurrency improvements implemented
-
-### Medium Priority ✅ COMPLETE
-2. **FileSystemStorage**: ✅ File-based locking for statistics implemented
-3. **OPFSStorage**: ✅ Browser-based locking for multi-tab scenarios implemented
-
-### Low Priority (Optional)
-4. **MemoryStorage**: No changes needed for typical use cases
-
-## Conclusion
-
-All recommended concurrency improvements from CONCURRENCY_ANALYSIS.md have been successfully implemented across the storage adapters:
-
-**✅ S3CompatibleStorage**: Full distributed concurrency support with locking, change logs, and statistics merging for multi-instance deployments.
-
-**✅ FileSystemStorage**: File-based locking implemented for multi-process coordination with statistics merging and lock expiration handling.
-
-**✅ OPFSStorage**: Browser-based locking implemented using localStorage for multi-tab coordination with statistics merging and graceful fallbacks.
-
-**✅ MemoryStorage**: No changes needed - appropriate for single-process scenarios.
-
-The implementation now provides comprehensive concurrency handling tailored to each storage adapter's specific deployment scenarios:
-- **Distributed coordination** for S3 multi-instance deployments
-- **Multi-process safety** for filesystem-based applications  
-- **Multi-tab coordination** for browser-based applications
-- **Lightweight operation** for memory-only scenarios
-
-All storage adapters now include proper statistics merging, lock cleanup, and graceful error handling to ensure data consistency and system reliability.

STORAGE_TESTING.md

@@ -1,122 +0,0 @@
-# Storage Testing in Brainy
-
-This document describes the testing approach for the storage system in Brainy, including the different storage types and the environment detection logic that determines which type is used.
-
-## Storage Architecture
-
-Brainy supports multiple storage types:
-
-1. **MemoryStorage**: In-memory storage for temporary data
-2. **FileSystemStorage**: File system storage for Node.js environments
-3. **OPFSStorage**: Origin Private File System storage for browser environments
-4. **S3CompatibleStorage**: Storage for Amazon S3, Google Cloud Storage, and custom S3-compatible services
-5. **R2Storage**: Storage for Cloudflare R2 (an alias for S3CompatibleStorage)
-
-The storage type is determined by the `createStorage` function in `src/storage/storageFactory.ts`, which uses the following logic:
-
-1. If `forceMemoryStorage` is true, use MemoryStorage
-2. If `forceFileSystemStorage` is true, use FileSystemStorage
-3. If a specific storage type is specified, use that type
-4. Otherwise, auto-detect the best storage type based on the environment:
-   - In a browser environment, try OPFS first
-   - In a Node.js environment, use FileSystemStorage
-   - Fall back to MemoryStorage if neither is available
-
-## Test Coverage
-
-The storage system is now tested with the following test cases:
-
-### Storage Adapters
-
-- **MemoryStorage**
-  - Creating and initializing MemoryStorage
-  - Basic operations (saving and retrieving metadata)
-
-- **FileSystemStorage**
-  - Creating and initializing FileSystemStorage in Node.js environment
-  - Basic operations (saving and retrieving metadata)
-  - Handling file system operations correctly
-
-- **OPFSStorage**
-  - Detecting OPFS availability correctly
-  - (Note: Complex OPFS operations are skipped due to the difficulty of mocking the OPFS API)
-
-- **S3CompatibleStorage and R2Storage**
-  - Basic structure for testing is provided but skipped by default as they require actual credentials
-  - These tests serve as documentation for how to test these storage types if needed
-
-### Environment Detection
-
-- **Forced Storage Types**
-  - Selecting MemoryStorage when forceMemoryStorage is true
-  - Selecting FileSystemStorage when forceFileSystemStorage is true
-
-- **Specific Storage Types**
-  - Selecting MemoryStorage when type is memory
-  - Selecting FileSystemStorage when type is filesystem
-
-- **Auto-detection**
-  - Selecting FileSystemStorage in Node.js environment
-  - Selecting OPFS in browser environment if available
-  - Falling back to MemoryStorage when OPFS is not available in browser
-
-## Running the Tests
-
-The storage tests can be run with:
-
-```bash
-npx vitest run tests/storage-adapters.test.ts
-```
-
-## Mock Implementations for Testing
-
-To facilitate testing of storage adapters in different environments, we've created mock implementations for both OPFS and S3 compatible storage:
-
-### OPFS Mock
-
-The OPFS (Origin Private File System) mock implementation provides a simulated file system environment for testing OPFS storage in a Node.js environment without requiring actual browser APIs. It's located in `/tests/mocks/opfs-mock.ts` and includes:
-
-- A mock file system using Maps to store directories and files
-- Mock implementations of FileSystemDirectoryHandle and FileSystemFileHandle
-- Functions to set up and clean up the mock environment
-- Support for all OPFS operations used by the OPFSStorage adapter
-
-### S3 Mock
-
-The S3 compatible storage mock implementation provides a simulated S3 bucket environment for testing S3 compatible storage in a Node.js environment without requiring actual S3 credentials. It's located in `/tests/mocks/s3-mock.ts` and includes:
-
-- A mock S3 storage using Maps to store buckets and objects
-- Mock implementations of S3 commands (CreateBucketCommand, PutObjectCommand, etc.)
-- Functions to set up and clean up the mock environment
-- Support for basic S3 operations used by the S3CompatibleStorage adapter
-
-## Running the Tests
-
-The storage tests can be run with:
-
-```bash
-# Run all storage tests
-npx vitest run tests/storage-adapters.test.ts
-
-# Run OPFS storage tests
-npx vitest run tests/opfs-storage.test.ts
-
-# Run S3 storage tests
-npx vitest run tests/s3-storage.test.ts
-```
-
-## Future Improvements
-
-1. **Increase Test Coverage**: Add more tests for specific methods of each storage adapter
-2. **Improve OPFS Testing**: Continue to enhance the OPFS mock implementation to better simulate browser environments
-3. **Enhance S3 Testing**: Improve the S3 mock implementation to fully support all operations used by the S3CompatibleStorage adapter, particularly:
-   - Fix issues with ListObjectsV2Command response handling
-   - Improve handling of metadata in GetObjectCommand
-   - Add better support for error cases and edge conditions
-4. **Integration Tests**: Add integration tests that test the storage system with real data
-5. **Browser Environment Testing**: Add tests that run in actual browser environments for OPFS storage
-6. **Real S3 Testing**: Add optional tests that can run against real S3 compatible services when credentials are provided
-
-## Conclusion
-
-The storage system in Brainy now has test coverage for the different storage types and the environment detection logic that determines which type is used. This ensures that the storage system works correctly in different environments and with different configurations.

TECHNICAL_GUIDES.md

@@ -1,864 +0,0 @@
-# Brainy Technical Guides
-
-<div align="center">
-<img src="./brainy.png" alt="Brainy Logo" width="200"/>
-</div>
-
-This document consolidates technical guides and documentation for specific aspects of the Brainy project.
-
-## Table of Contents
-
-- [Vector Dimension Standardization](#vector-dimension-standardization)
-- [Dimension Mismatch Issue](#dimension-mismatch-issue)
-- [Production Migration Guide](#production-migration-guide)
-- [Threading Implementation](#threading-implementation)
-- [Storage Testing](#storage-testing)
-- [Scaling Strategy](#scaling-strategy)
-- [Metadata Handling](#metadata-handling)
-- [Model Loading](#model-loading)
-
-## Vector Dimension Standardization
-
-Brainy uses a standardized approach to vector dimensions to ensure consistency across the system. This section explains how vector dimensions are handled and standardized.
-
-### Default Dimensions
-
-The default dimension for vectors in Brainy is 512, which is the output dimension of the Universal Sentence Encoder (USE) model used for text embeddings.
-
-### Dimension Validation
-
-Brainy validates vector dimensions during database operations to ensure consistency:
-
-1. During initialization, vectors with mismatched dimensions are skipped
-2. When adding new vectors, their dimensions are validated against the expected dimension
-3. When searching, query vectors are validated to ensure they match the expected dimension
-
-### Configuration
-
-You can configure the expected dimension when creating a BrainyData instance:
-
-```typescript
-const db = new BrainyData({
-  dimensions: 768 // Use a different dimension (e.g., for BERT embeddings)
-})
-```
-
-If not specified, the default dimension of 512 is used.
-
-### Handling Dimension Changes
-
-When changing the embedding model or dimension size, you need to:
-
-1. Back up your existing data
-2. Re-embed all vectors with the new embedding function
-3. Update the dimension configuration
-
-### Standardization Changes
-
-As of version 0.18.0, Brainy has standardized all vector dimensions to 512, which is the dimension used by the Universal Sentence Encoder. This change ensures consistency between data insertion, storage, and search operations, eliminating potential dimension mismatch issues.
-
-#### Changes Made
-
-1. **Fixed Dimension Value**: Vector dimensions are now fixed at 512 throughout the codebase.
-2. **Removed Configuration Option**: The `dimensions` configuration option has been removed from `BrainyDataConfig`.
-3. **Consistent Validation**: All vectors are validated to ensure they have exactly 512 dimensions.
-
-#### Rationale
-
-Previously, vector dimensions were configurable, which could lead to mismatches between:
-- Vectors stored in the database
-- The expected dimensions in the HNSW index
-- Vectors generated by the embedding function
-
-These mismatches could cause search functionality to break, as vectors with different dimensions would be skipped during initialization.
-
-By standardizing all vectors to 512 dimensions (matching the Universal Sentence Encoder's output), we ensure that:
-- All vectors in the database have consistent dimensions
-- The HNSW index always works with vectors of the expected size
-- Search queries always match the dimension of stored vectors
-
-#### Impact on Existing Code
-
-- The `dimensions` property in `BrainyDataConfig` has been removed
-- Attempting to add vectors with dimensions other than 512 will throw an error
-- Existing data with non-512 dimensions will be skipped during initialization
-
-#### Migration
-
-If you have existing data with dimensions other than 512, you can use the provided `fix-dimension-mismatch.js` script to re-embed your data with the correct dimensions:
-
-```bash
-node fix-dimension-mismatch.js
-```
-
-This script:
-1. Creates a backup of your existing data
-2. Re-embeds all nouns using the Universal Sentence Encoder (512 dimensions)
-3. Recreates all verb relationships
-4. Verifies that search functionality works correctly
-
-#### Best Practices
-
-- Always use the built-in embedding function for text data, which will automatically produce 512-dimensional vectors
-- If you're creating vectors manually, ensure they have exactly 512 dimensions
-- When migrating from previous versions, run the `fix-dimension-mismatch.js` script to ensure all data has consistent dimensions
-
-## Dimension Mismatch Issue
-
-This section summarizes a dimension mismatch issue that occurred in Brainy and provides recommendations for handling similar issues.
-
-### What Happened
-
-The search functionality in Brainy stopped working because of a dimension mismatch between stored vectors and the expected dimensions in the current version of the codebase:
-
-1. **Previous State**: The system was using vectors with 3 dimensions.
-2. **Current State**: The system now expects 512-dimensional vectors from the Universal Sentence Encoder.
-3. **Code Change**: Recent updates introduced dimension validation during initialization, which skips vectors with mismatched dimensions.
-4. **Result**: During initialization, vectors with 3 dimensions were skipped, resulting in an empty search index and no search results.
-
-### Root Cause Analysis
-
-The root cause was identified by examining the codebase:
-
-1. In `brainyData.ts`, the `init()` method checks if vector dimensions match the expected dimensions:
-   ```javascript
-   if (noun.vector.length !== this._dimensions) {
-     console.warn(
-       `Skipping noun ${noun.id} due to dimension mismatch: expected ${this._dimensions}, got ${noun.vector.length}`
-     )
-     // Skip this noun and continue with the next one
-     return;
-   }
-   ```
-
-2. The default dimension is set to 512 in the constructor:
-   ```javascript
-   this._dimensions = config.dimensions || 512
-   ```
-
-3. The `UniversalSentenceEncoder` class in `embedding.ts` produces 512-dimensional vectors:
-   ```javascript
-   // Return a zero vector of appropriate dimension (512 is the default for USE)
-   return new Array(512).fill(0)
-   ```
-
-This indicates that the system previously used 3-dimensional vectors, but after the update, it expects 512-dimensional vectors. The existing data was not migrated, causing the search functionality to break.
-
-### Solution Implemented
-
-We created and tested a fix script (`fix-dimension-mismatch.js`) that:
-
-1. Creates a backup of the existing data
-2. Reads all noun files directly from the filesystem
-3. For each noun:
-   - Extracts text from metadata
-   - Deletes the existing noun
-   - Re-adds the noun with the same ID but using the current embedding function
-4. Recreates all verb relationships between the re-embedded nouns
-5. Verifies that search works by performing a test search
-
-The script successfully fixed the issue by re-embedding all data with the correct dimensions, and search functionality was restored.
-
-### Production Recommendations
-
-For production environments, we recommend:
-
-#### 1. Use the Enhanced Migration Script
-
-We've created a comprehensive production migration guide that includes:
-
-- Enhanced backup strategies with metadata
-- Batching for large datasets
-- Robust error handling and recovery
-- Progress monitoring and reporting
-- A parallel database approach for mission-critical systems
-
-#### 2. Implement Preventive Measures
-
-To prevent similar issues in the future:
-
-- **Version Tracking**: Add version information to stored vectors
-- **Auto-Migration**: Enhance initialization to automatically re-embed mismatched vectors
-- **Regular Validation**: Implement a database validation process
-- **Documentation**: Document embedding changes in release notes
-
-#### 3. Scheduling and Communication
-
-- Schedule the migration during a maintenance window
-- Communicate the change to all stakeholders
-- Have a rollback plan in case of issues
-- Monitor the system after the migration
-
-## Production Migration Guide
-
-This section provides a comprehensive guide for migrating Brainy databases in production environments, particularly when dealing with dimension changes or other breaking changes.
-
-### Preparation
-
-Before starting the migration:
-
-1. **Create a Backup**: Always create a complete backup of your database before migration
-2. **Test the Migration**: Test the migration process on a copy of your production data
-3. **Schedule Downtime**: Plan for a maintenance window if the migration requires downtime
-4. **Communicate**: Inform all stakeholders about the planned migration
-
-### Migration Strategies
-
-#### Strategy 1: In-Place Migration
-
-For smaller databases or when downtime is acceptable:
-
-1. Stop all services that use the database
-2. Run the migration script
-3. Verify the migration was successful
-4. Restart the services
-
-#### Strategy 2: Parallel Database
-
-For mission-critical systems or large databases:
-
-1. Create a new database instance
-2. Run the migration script to populate the new database
-3. Test the new database thoroughly
-4. Switch over to the new database with minimal downtime
-
-### Migration Script
-
-The enhanced migration script includes:
-
-1. **Comprehensive Backup**: Creates a complete backup with all metadata
-2. **Batched Processing**: Processes data in batches to avoid memory issues
-3. **Progress Tracking**: Shows progress and estimated time remaining
-4. **Error Handling**: Robust error handling with automatic retries
-5. **Validation**: Validates the migrated data to ensure correctness
-
-### Post-Migration Steps
-
-After completing the migration:
-
-1. **Verify Data Integrity**: Run validation queries to ensure data was migrated correctly
-2. **Monitor Performance**: Watch for any performance issues after the migration
-3. **Update Documentation**: Document the migration and any changes to the data structure
-4. **Retain Backups**: Keep the pre-migration backups for a reasonable period
-
-## Threading Implementation
-
-Brainy includes comprehensive multithreading support to improve performance across all environments. This section explains how threading is implemented and used in the project.
-
-### Threading Architecture
-
-The threading architecture in Brainy is designed to work consistently across different environments:
-
-1. **Browser Environment**: Uses Web Workers for parallel processing
-2. **Node.js Environment**: Uses Worker Threads for parallel processing
-3. **Fallback**: Gracefully falls back to sequential processing when threading is not available
-
-### Overview
-
-Brainy uses a unified threading approach that adapts to the environment it's running in:
-
-1. **Node.js**: Uses Worker Threads API (optimized for Node.js 24+)
-2. **Browser**: Uses Web Workers API
-3. **Fallback**: Executes on the main thread when neither Worker Threads nor Web Workers are available
-
-This implementation ensures that compute-intensive operations (like embedding generation and vector calculations) can be performed efficiently without blocking the main thread, while maintaining compatibility across all environments.
-
-### Environment Detection
-
-Brainy automatically detects the environment it's running in:
-
-```typescript
-// From unified.ts
-export const environment = {
-  isBrowser: typeof window !== 'undefined',
-  isNode: typeof process !== 'undefined' && process.versions && process.versions.node,
-  isServerless: typeof window === 'undefined' && 
-    (typeof process === 'undefined' || !process.versions || !process.versions.node)
-}
-```
-
-Additional environment detection functions are available in `src/utils/environment.ts`:
-
-```typescript
-// Check if threading is available
-export function isThreadingAvailable(): boolean {
-  return areWebWorkersAvailable() || areWorkerThreadsAvailable();
-}
-
-// Check if Web Workers are available (browser)
-export function areWebWorkersAvailable(): boolean {
-  return isBrowser() && typeof Worker !== 'undefined';
-}
-
-// Check if Worker Threads are available (Node.js)
-export function areWorkerThreadsAvailable(): boolean {
-  if (!isNode()) return false;
-  try {
-    require('worker_threads');
-    return true;
-  } catch (e) {
-    return false;
-  }
-}
-```
-
-### Thread Execution
-
-The core of the threading implementation is the `executeInThread` function in `src/utils/workerUtils.ts`:
-
-```typescript
-export function executeInThread<T>(fnString: string, args: any): Promise<T> {
-  if (environment.isNode) {
-    return executeInNodeWorker<T>(fnString, args)
-  } else if (environment.isBrowser && typeof window !== 'undefined' && window.Worker) {
-    return executeInWebWorker<T>(fnString, args)
-  } else {
-    // Fallback to main thread execution
-    try {
-      const fn = new Function('return ' + fnString)()
-      return Promise.resolve(fn(args) as T)
-    } catch (error) {
-      return Promise.reject(error)
-    }
-  }
-}
-```
-
-This function:
-1. Checks if it's running in Node.js and uses Worker Threads if available
-2. Checks if it's running in a browser and uses Web Workers if available
-3. Falls back to executing on the main thread if neither is available
-
-### Node.js Implementation
-
-For Node.js environments, Brainy uses the Worker Threads API with optimizations for Node.js 24:
-
-```typescript
-function executeInNodeWorker<T>(fnString: string, args: any): Promise<T> {
-  // Implementation using Node.js Worker Threads
-  // Includes worker pool management for better performance
-  // Uses dynamic imports with the 'node:' protocol prefix
-  // ...
-}
-```
-
-Key optimizations:
-- Worker pool to reuse workers and minimize overhead
-- Dynamic imports with the `node:` protocol prefix
-- Error handling and cleanup
-
-### Browser Implementation
-
-For browser environments, Brainy uses the Web Workers API:
-
-```typescript
-function executeInWebWorker<T>(fnString: string, args: any): Promise<T> {
-  // Implementation using browser Web Workers
-  // Creates a blob URL for the worker code
-  // Handles message passing and error handling
-  // ...
-}
-```
-
-Key features:
-- Creates workers using Blob URLs
-- Proper cleanup of resources (terminating workers and revoking URLs)
-- Error handling
-
-### Fallback Mechanism
-
-When neither Worker Threads nor Web Workers are available, Brainy falls back to executing on the main thread:
-
-```typescript
-// Fallback to main thread execution
-try {
-  const fn = new Function('return ' + fnString)()
-  return Promise.resolve(fn(args) as T)
-} catch (error) {
-  return Promise.reject(error)
-}
-```
-
-This ensures that Brainy works in all environments, even if threading is not available.
-
-### Key Threading Features
-
-1. **Parallel Batch Processing**: Add multiple items concurrently with controlled parallelism
-2. **Multithreaded Vector Search**: Perform distance calculations in parallel for faster search operations
-3. **Threaded Embedding Generation**: Generate embeddings in separate threads to avoid blocking the main thread
-4. **Worker Reuse**: Maintains a pool of workers to avoid the overhead of creating and terminating workers
-5. **Model Caching**: Initializes the embedding model once per worker and reuses it for multiple operations
-6. **Batch Embedding**: Processes multiple items in a single embedding operation for better performance
-7. **Automatic Environment Detection**: Adapts to browser (Web Workers) and Node.js (Worker Threads) environments
-
-### Usage
-
-Threading is used automatically in several parts of Brainy:
-
-1. **Embedding Generation**: When using `createThreadedEmbeddingFunction()`
-2. **Batch Operations**: When using `addBatch()` with multiple items
-3. **Vector Search**: When performing similarity searches with large datasets
-
-You can control threading behavior through configuration:
-
-```typescript
-const db = new BrainyData({
-  performance: {
-    useParallelization: true, // Enable multithreaded operations
-    maxWorkers: 4,            // Maximum number of worker threads
-    batchSize: 50             // Number of items to process in a single batch
-  }
-})
-```
-
-The threading implementation is used throughout Brainy, particularly for compute-intensive operations like embedding generation:
-
-```typescript
-export function createThreadedEmbeddingFunction(
-  model: EmbeddingModel
-): EmbeddingFunction {
-  const embeddingFunction = createEmbeddingFunction(model)
-
-  return async (data: any): Promise<Vector> => {
-    // Convert the embedding function to a string
-    const fnString = embeddingFunction.toString()
-
-    // Execute the embedding function in a thread
-    return await executeInThread<Vector>(fnString, data)
-  }
-}
-```
-
-### Implementation Details
-
-The threading implementation includes:
-
-1. **Worker Pool**: A reusable pool of workers that avoids the overhead of creating and destroying workers
-2. **Task Queue**: A queue of tasks that are distributed to available workers
-3. **Message Passing**: A standardized message format for communication between the main thread and workers
-4. **Error Handling**: Robust error handling for worker failures
-5. **Resource Management**: Proper cleanup of resources when workers are no longer needed
-
-### Testing
-
-Two test scripts are provided to verify the threading implementation:
-
-1. `demo/test-browser-worker.html`: Tests the threading implementation in a browser environment
-2. `demo/test-fallback.html`: Tests the fallback mechanism when threading is not available
-
-To run these tests:
-1. Build the project: `npm run build`
-2. Start a local server: `npx http-server`
-3. Open the test pages in a browser:
-   - http://localhost:8080/demo/test-browser-worker.html
-   - http://localhost:8080/demo/test-fallback.html
-
-### Compatibility
-
-The threading implementation has been tested and works in:
-
-- Node.js 24+ (using Worker Threads)
-- Modern browsers (using Web Workers):
-  - Chrome
-  - Firefox
-  - Safari
-  - Edge
-- Environments without threading support (using fallback mechanism)
-
-## Storage Testing
-
-This section provides guidance on testing storage adapters in Brainy, including file system storage, OPFS storage, and S3-compatible storage.
-
-### Testing Approach
-
-When testing storage adapters, consider the following:
-
-1. **Isolation**: Test each storage adapter in isolation
-2. **Edge Cases**: Test edge cases like empty data, large data, and invalid data
-3. **Error Handling**: Test error conditions and recovery
-4. **Performance**: Test performance with different data sizes
-5. **Concurrency**: Test concurrent access to the same data
-
-### Testing File System Storage
-
-To test the file system storage adapter:
-
-1. Create a temporary directory for testing
-2. Initialize a BrainyData instance with the file system storage adapter
-3. Perform CRUD operations on nouns and verbs
-4. Verify that data is correctly stored and retrieved
-5. Clean up the temporary directory after testing
-
-### Testing OPFS Storage
-
-To test the Origin Private File System (OPFS) storage adapter:
-
-1. Use a browser environment (real or simulated)
-2. Initialize a BrainyData instance with the OPFS storage adapter
-3. Perform CRUD operations on nouns and verbs
-4. Verify that data is correctly stored and retrieved
-5. Test persistence across page reloads
-
-### Testing S3-Compatible Storage
-
-To test the S3-compatible storage adapter:
-
-1. Use a mock S3 service or a real S3-compatible service
-2. Configure the S3 storage adapter with appropriate credentials
-3. Perform CRUD operations on nouns and verbs
-4. Verify that data is correctly stored and retrieved
-5. Test error conditions like network failures and permission issues
-
-### Automated Testing
-
-Brainy includes automated tests for all storage adapters in the `tests/` directory:
-
-1. `tests/filesystem-storage.test.ts`: Tests for the file system storage adapter
-2. `tests/opfs-storage.test.ts`: Tests for the OPFS storage adapter
-3. `tests/s3-storage.test.ts`: Tests for the S3-compatible storage adapter
-
-These tests can be run using the standard test commands:
-
-```bash
-# Run all storage tests
-npm test -- tests/*-storage.test.ts
-
-# Run specific storage tests
-npm test -- tests/filesystem-storage.test.ts
-```
-
-## Scaling Strategy
-
-Brainy is designed to handle datasets of various sizes, from small collections to large-scale deployments. This section outlines strategies for scaling Brainy to handle terabyte-scale data.
-
-### Scaling Challenges
-
-When scaling Brainy to handle very large datasets, several challenges need to be addressed:
-
-1. **Memory Constraints**: Vector data can consume significant memory
-2. **Search Performance**: Maintaining fast search with millions of vectors
-3. **Storage Efficiency**: Optimizing how vectors are stored and retrieved
-4. **Concurrent Access**: Handling multiple simultaneous operations
-
-### Scaling Approaches
-
-#### 1. Disk-Based HNSW
-
-For datasets that can't fit entirely in memory:
-
-- **Memory-Mapped Files**: Store vectors on disk but access them as if they were in memory
-- **Partial Loading**: Load only the most frequently accessed vectors into memory
-- **Intelligent Caching**: Cache vectors based on access patterns
-- **Optimized I/O**: Minimize disk operations through batching and prefetching
-
-Implementation:
-
-```typescript
-const db = new BrainyData({
-  hnswOptimized: {
-    useDiskBasedIndex: true,
-    memoryThreshold: 1024 * 1024 * 1024, // 1GB threshold
-    cacheSize: 100000 // Number of vectors to keep in memory
-  }
-})
-```
-
-#### 2. Distributed HNSW
-
-For extremely large datasets that need to be distributed across multiple machines:
-
-- **Sharding**: Partition the vector space into multiple shards
-- **Routing**: Direct queries to the appropriate shard(s)
-- **Result Merging**: Combine results from multiple shards
-- **Load Balancing**: Distribute data evenly across shards
-
-Implementation:
-
-```typescript
-// On each node
-const nodeDb = new BrainyData({
-  sharding: {
-    enabled: true,
-    nodeId: 'node-1',
-    totalNodes: 4,
-    shardingFunction: (vector) => {
-      // Determine which shard this vector belongs to
-      return hashVector(vector) % 4
-    }
-  }
-})
-```
-
-#### 3. Hybrid Solutions
-
-Combining multiple techniques for optimal performance:
-
-- **Product Quantization**: Compress vectors to reduce memory usage
-- **Multi-Tier Storage**: Use fast storage for frequently accessed data and slower storage for less frequently accessed data
-- **Hierarchical Clustering**: Group similar vectors together for more efficient search
-
-Implementation:
-
-```typescript
-const db = new BrainyData({
-  hnswOptimized: {
-    productQuantization: {
-      enabled: true,
-      numSubvectors: 16,
-      numCentroids: 256
-    },
-    multiTierStorage: {
-      enabled: true,
-      tiers: [
-        { type: 'memory', capacity: '2GB' },
-        { type: 'ssd', capacity: '100GB' },
-        { type: 'hdd', capacity: '1TB' }
-      ]
-    }
-  }
-})
-```
-
-### Performance Optimizations
-
-Regardless of the scaling approach, these optimizations can improve performance:
-
-1. **Batch Operations**: Process multiple items at once to reduce overhead
-2. **Parallel Processing**: Use multiple threads for compute-intensive operations
-3. **Index Tuning**: Adjust HNSW parameters based on dataset characteristics
-4. **Compression**: Use vector compression techniques to reduce memory usage
-5. **Pruning**: Periodically remove unused or low-quality vectors
-
-### Monitoring and Maintenance
-
-To ensure optimal performance as your dataset grows:
-
-1. **Performance Metrics**: Track search latency, memory usage, and throughput
-2. **Index Health**: Monitor index quality and rebuild when necessary
-3. **Resource Utilization**: Watch CPU, memory, and disk usage
-4. **Scaling Triggers**: Set thresholds for when to scale up or out
-
-### Recommended Scaling Path
-
-As your dataset grows, follow this progression:
-
-1. **Small Datasets** (< 1M vectors): Standard in-memory HNSW
-2. **Medium Datasets** (1M-10M vectors): Optimized in-memory HNSW with product quantization
-3. **Large Datasets** (10M-100M vectors): Disk-based HNSW with intelligent caching
-4. **Very Large Datasets** (> 100M vectors): Distributed HNSW with sharding
-
-## Metadata Handling
-
-This section explains how metadata is handled in Brainy, including storage, retrieval, and best practices.
-
-### Metadata Structure
-
-In Brainy, metadata is associated with both nouns (entities) and verbs (relationships):
-
-- **Noun Metadata**: Describes properties of an entity
-- **Verb Metadata**: Describes properties of a relationship between entities
-
-Metadata is stored as JSON objects and can include any valid JSON data:
-
-```typescript
-// Noun metadata example
-const nounMetadata = {
-  noun: NounType.Thing,
-  category: 'animal',
-  tags: ['pet', 'mammal'],
-  attributes: {
-    size: 'medium',
-    lifespan: '10-15 years'
-  },
-  created: new Date().toISOString()
-}
-
-// Verb metadata example
-const verbMetadata = {
-  verb: VerbType.RelatedTo,
-  strength: 0.85,
-  bidirectional: true,
-  created: new Date().toISOString()
-}
-```
-
-### Adding Metadata
-
-Metadata is added when creating nouns and verbs:
-
-```typescript
-// Adding a noun with metadata
-const catId = await db.add("Cats are independent pets", {
-  noun: NounType.Thing,
-  category: 'animal',
-  tags: ['pet', 'mammal'],
-  attributes: {
-    size: 'medium',
-    lifespan: '10-15 years'
-  }
-})
-
-// Adding a verb with metadata
-await db.addVerb(catId, dogId, {
-  verb: VerbType.RelatedTo,
-  strength: 0.85,
-  bidirectional: true
-})
-```
-
-### Retrieving Metadata
-
-Metadata is included when retrieving nouns and verbs:
-
-```typescript
-// Get a noun with its metadata
-const noun = await db.get(catId)
-console.log(noun.metadata)
-
-// Get verbs with their metadata
-const verbs = await db.getVerbsBySource(catId)
-verbs.forEach(verb => console.log(verb.metadata))
-```
-
-### Updating Metadata
-
-Metadata can be updated using the `updateMetadata` method:
-
-```typescript
-// Update noun metadata
-await db.updateMetadata(catId, {
-  ...existingMetadata,
-  tags: [...existingMetadata.tags, 'domestic'],
-  lastUpdated: new Date().toISOString()
-})
-
-// Update verb metadata
-await db.updateVerbMetadata(verbId, {
-  ...existingVerbMetadata,
-  strength: 0.9,
-  lastUpdated: new Date().toISOString()
-})
-```
-
-### Metadata Storage
-
-Metadata is stored differently depending on the storage adapter:
-
-- **FileSystemStorage**: Metadata is stored in separate JSON files
-- **OPFSStorage**: Metadata is stored in separate files in the Origin Private File System
-- **S3CompatibleStorage**: Metadata is stored as separate objects in S3
-- **MemoryStorage**: Metadata is stored in memory as part of the noun or verb object
-
-### Metadata Indexing
-
-Brainy does not currently index metadata for direct querying. To find nouns or verbs based on metadata, you need to:
-
-1. Retrieve all relevant nouns or verbs
-2. Filter them based on metadata properties
-
-```typescript
-// Find all nouns with a specific tag
-const allNouns = await db.getAllNouns()
-const nounsWithTag = allNouns.filter(noun => 
-  noun.metadata.tags && noun.metadata.tags.includes('domestic')
-)
-```
-
-### Best Practices
-
-1. **Consistent Structure**: Use a consistent metadata structure across similar entities
-2. **Required Fields**: Always include required fields like `noun` and `verb` types
-3. **Timestamps**: Add creation and update timestamps for tracking changes
-4. **Avoid Large Objects**: Keep metadata reasonably sized to avoid performance issues
-5. **Versioning**: Consider adding a version field to track metadata schema changes
-
-## Model Loading
-
-This section explains how model loading works in Brainy, particularly for the Universal Sentence Encoder (USE) model used for text embeddings.
-
-### Model Loading Process
-
-Brainy uses TensorFlow.js to load and run the Universal Sentence Encoder model. The loading process follows these steps:
-
-1. **Check Cache**: Check if the model is already loaded and cached
-2. **Load Model**: If not cached, load the model from the appropriate source
-3. **Warm Up**: Run a sample input through the model to initialize it
-4. **Cache Model**: Store the loaded model for future use
-
-### Model Sources
-
-The Universal Sentence Encoder model can be loaded from different sources:
-
-1. **Bundled Model**: A simplified version of the model is bundled with Brainy
-2. **TensorFlow Hub**: The full model can be loaded from TensorFlow Hub
-3. **Local Path**: The model can be loaded from a local path
-
-### Loading Modes
-
-Brainy supports different loading modes for the Universal Sentence Encoder:
-
-1. **Lazy Loading**: The model is loaded only when needed (default)
-2. **Eager Loading**: The model is loaded during initialization
-3. **Preloaded**: A pre-loaded model is provided to Brainy
-
-### Configuration
-
-You can configure model loading behavior when creating a BrainyData instance:
-
-```typescript
-const db = new BrainyData({
-  embedding: {
-    modelLoadingMode: 'eager', // 'lazy', 'eager', or 'preloaded'
-    modelPath: 'path/to/local/model', // Optional local model path
-    useSimplifiedModel: true, // Use the bundled simplified model
-    cacheModel: true // Cache the model for reuse
-  }
-})
-```
-
-### Threaded Model Loading
-
-For better performance, Brainy can load and run the model in a separate thread:
-
-```typescript
-const db = new BrainyData({
-  embedding: {
-    useThreading: true, // Load and run the model in a separate thread
-    maxWorkers: 4 // Maximum number of worker threads for model inference
-  }
-})
-```
-
-### Model Caching
-
-To improve performance, Brainy caches the loaded model:
-
-1. **In-Memory Caching**: The model is cached in memory for reuse
-2. **Worker Caching**: In threaded mode, each worker caches its own model instance
-3. **Cross-Request Caching**: In server environments, the model is cached across requests
-
-### Troubleshooting
-
-Common issues with model loading and their solutions:
-
-1. **Memory Issues**: If you encounter memory issues, try:
-   - Using the simplified model (`useSimplifiedModel: true`)
-   - Loading the model in a separate thread (`useThreading: true`)
-   - Reducing the batch size for embedding operations
-
-2. **Loading Failures**: If the model fails to load, try:
-   - Checking network connectivity (for TensorFlow Hub loading)
-   - Verifying the local model path (for local loading)
-   - Using the bundled model as a fallback
-
-3. **Performance Issues**: If embedding is slow, try:
-   - Using threaded embedding (`useThreading: true`)
-   - Increasing the number of workers (`maxWorkers`)
-   - Using batch embedding for multiple items
-
-### Best Practices
-
-1. **Eager Loading**: For production environments, use eager loading to avoid delays during operation
-2. **Threaded Embedding**: Use threaded embedding for better performance, especially for batch operations
-3. **Simplified Model**: Use the simplified model for resource-constrained environments
-4. **Batch Processing**: Process multiple items in a single embedding operation for better performance

TESTING.md

@@ -1,531 +0,0 @@
-# Brainy Testing Guide
-
-<div align="center">
-<img src="./brainy.png" alt="Brainy Logo" width="200"/>
-</div>
-
-This document provides comprehensive information about testing in the Brainy project, including test configuration, expected messages, reporting tools, and testing strategies.
-
-## Table of Contents
-
-- [Vitest Configuration](#vitest-configuration)
-- [Test Scripts](#test-scripts)
-- [Pretty Test Reporter](#pretty-test-reporter)
-- [Expected Messages During Test Execution](#expected-messages-during-test-execution)
-- [Storage Testing](#storage-testing)
-- [Test Matrix](#test-matrix)
-- [API Integration Test Troubleshooting](#api-integration-test-troubleshooting)
-- [Testing Best Practices](#testing-best-practices)
-
-## Vitest Configuration
-
-The Vitest configuration has been updated to provide cleaner, more focused test output that shows only successes, failures, and a nice summary report at the end.
-
-### Reporter Configuration
-
-- Multiple reporters configured for different levels of detail:
-  - Default reporter for basic progress and summary
-  - JSON reporter for machine-readable output
-  - Pretty reporter for visually appealing summaries
-
-```javascript
-reporters: [
-  // Default reporter for basic progress and summary
-  [
-    'default',
-    {
-      summary: true,
-      reportSummary: true,
-      successfulTestOnly: false,
-      outputFile: false
-    }
-  ],
-  // JSON reporter for machine-readable output
-  [
-    'json',
-    {
-      outputFile: './test-results.json'
-    }
-  ]
-]
-```
-
-### Output Settings
-
-- Set `hideSkippedTests: true` to reduce noise from skipped tests
-- Set `printConsoleTrace: false` to only show stack traces for failed tests
-- Added output formatting options:
-  ```javascript
-  outputDiffLines: 5;      // Limit diff output lines for cleaner error reports
-  outputFileMaxLines: 40;  // Limit file output lines for cleaner error reports
-  outputTruncateLength: 80; // Truncate long output lines
-  ```
-
-### Console Output Filtering
-
-Enhanced console output filtering to be more aggressive:
-
-- Added a whitelist approach for stdout, only allowing specific test-related patterns
-- Enhanced stderr filtering to only show actual errors
-- Expanded the list of noise patterns to filter out common debug messages
-
-### Recent Improvements
-
-The Vitest configuration has been further enhanced to provide more detailed reporting and better console output suppression:
-
-1. **Multiple Reporters**
-   - Default reporter for basic progress and summary
-   - Verbose reporter for detailed information about failures
-   - JSON reporter for machine-readable output
-
-2. **Enhanced Console Output Suppression**
-   - Added a whitelist approach for stdout, only allowing specific test-related patterns
-   - Enhanced stderr filtering to only show actual errors
-   - Expanded the list of noise patterns to filter out common debug messages
-
-3. **Fixed Duplicate Summary Output**
-   - The test output was showing duplicate summary information at the end of test runs
-   - Fixed by simplifying the reporters configuration to use only the necessary reporters
-   - Removed the verbose reporter which was causing duplicate summary output
-
-## Test Scripts
-
-Brainy provides several test scripts for different testing scenarios:
-
-```bash
-# Run all tests
-npm test
-
-# Run tests with comprehensive reporting
-npm run test:report
-
-# Run tests in watch mode
-npm test:watch
-
-# Run tests with UI
-npm test:ui
-
-# Run specific test suites
-npm run test:node
-npm run test:browser
-npm run test:core
-
-# Run tests with coverage
-npm run test:coverage
-
-# Detailed report with verbose output
-npm run test:report:detailed
-
-# Generate JSON report for machine processing
-npm run test:report:json
-
-# Run tests in silent mode (minimal output)
-npm run test:silent
-
-# Show only progress and errors
-npm run test:progress-only
-
-# Run tests with pretty reporter
-npm run test:report:pretty
-```
-
-## Pretty Test Reporter
-
-The Pretty Test Reporter provides a visually appealing summary of test results with colors, symbols, and formatted output. It enhances the standard Vitest output with a clear, easy-to-read summary at the end of test runs.
-
-### Features
-
-- 🎨 **Colorful Output**: Uses colors to distinguish between passed, failed, and skipped tests
-- 📊 **Tabular Format**: Displays test results in a clean, tabular format
-- 📝 **Detailed Summary**: Shows overall test statistics and file-by-file breakdown
-- ❌ **Error Reporting**: Clearly lists any failed tests with their error messages
-- ⏱️ **Timing Information**: Displays test duration in a human-readable format
-
-### Example Output
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-📊 TEST SUMMARY REPORT
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Test Run Completed in: 7.9s
-Date: 7/28/2025, 11:22:54 AM
-Total Test Files: 1
-Total Tests: 19
-
-Results:
-  ✓ Passed: 19
-  ✗ Failed: 0
-  ○ Skipped: 0
-
-Test Files:
-┌──────────────────────────────────────────────────┬──────────┬──────────┬──────────┐
-│ File                                              │ Passed    │ Failed    │ Skipped   │
-├──────────────────────────────────────────────────┼──────────┼──────────┼──────────┤
-│ core.test.ts                                      │ 19        │ 0         │ 0         │
-└──────────────────────────────────────────────────┴──────────┴──────────┴──────────┘
-
- PASSED  All tests passed successfully!
-```
-
-### Implementation Details
-
-The pretty reporter is implemented as a custom Vitest reporter in `src/testing/prettySummaryReporter.ts`. It:
-
-1. Collects test information during the test run
-2. Tracks passed, failed, and skipped tests
-3. Organizes results by test file
-4. Generates a formatted summary at the end of the test run
-
-### Usage
-
-To run tests with the pretty reporter, use the following npm script:
-
-```bash
-npm run test:report:pretty
-```
-
-You can also specify specific test files:
-
-```bash
-npm run test:report:pretty -- tests/core.test.ts
-```
-
-### Customization
-
-If you need to modify the reporter's appearance or behavior, you can edit the `prettySummaryReporter.ts` file. The main visual elements are in the `printSummary` method.
-
-## Expected Messages During Test Execution
-
-This section explains the various messages and errors that appear during test execution and why they are expected.
-
-### Fixed Issues
-
-#### Duplicate Summary Output
-- **Issue**: Previously, test summaries were appearing twice at the end of test runs
-- **Fix**: Removed the verbose reporter from the configuration, keeping only the default and JSON reporters
-- **Status**: Resolved
-
-### Expected Error Messages
-
-The following error messages appear during test runs and are expected as part of the test suite:
-
-#### S3 Storage Tests
-- **Error**: `[MOCK S3] Error processing command: Error: NoSuchKey: The specified key does not exist.`
-- **Source**: `tests/s3-storage.test.ts`
-- **Explanation**: This error is expected and is part of the test for the S3 storage adapter. The test intentionally deletes a noun and then tries to retrieve it to verify it was properly deleted.
-
-#### Dimension Mismatch Errors
-- **Error**: `Failed to add vector: Error: Vector dimension mismatch: expected 512, got X`
-- **Source**: `tests/dimension-standardization.test.ts` and `tests/core.test.ts`
-- **Explanation**: These tests specifically verify that the system correctly rejects vectors with incorrect dimensions. The error messages confirm that the validation is working as expected.
-
-#### API Integration Test Failure
-- **Error**: `expected 500 to be 200 // Object.is equality`
-- **Source**: `tests/api-integration.test.ts`
-- **Explanation**: This appears to be an actual test failure that should be investigated separately. The test expects a 200 status code but is receiving a 500 error.
-
-### Conclusion
-
-Most of the error messages seen during test execution are expected and are part of testing error handling paths. These messages confirm that the system is correctly handling error conditions as designed.
-
-## Storage Testing
-
-This section describes the testing approach for the storage system in Brainy, including the different storage types and the environment detection logic that determines which type is used.
-
-### Storage Architecture
-
-Brainy supports multiple storage types:
-
-1. **MemoryStorage**: In-memory storage for temporary data
-2. **FileSystemStorage**: File system storage for Node.js environments
-3. **OPFSStorage**: Origin Private File System storage for browser environments
-4. **S3CompatibleStorage**: Storage for Amazon S3, Google Cloud Storage, and custom S3-compatible services
-5. **R2Storage**: Storage for Cloudflare R2 (an alias for S3CompatibleStorage)
-
-The storage type is determined by the `createStorage` function in `src/storage/storageFactory.ts`, which uses the following logic:
-
-1. If `forceMemoryStorage` is true, use MemoryStorage
-2. If `forceFileSystemStorage` is true, use FileSystemStorage
-3. If a specific storage type is specified, use that type
-4. Otherwise, auto-detect the best storage type based on the environment:
-   - In a browser environment, try OPFS first
-   - In a Node.js environment, use FileSystemStorage
-   - Fall back to MemoryStorage if neither is available
-
-### Test Coverage
-
-The storage system is now tested with the following test cases:
-
-#### Storage Adapters
-
-- **MemoryStorage**
-  - Creating and initializing MemoryStorage
-  - Basic operations (saving and retrieving metadata)
-
-- **FileSystemStorage**
-  - Creating and initializing FileSystemStorage in Node.js environment
-  - Basic operations (saving and retrieving metadata)
-  - Handling file system operations correctly
-
-- **OPFSStorage**
-  - Detecting OPFS availability correctly
-  - (Note: Complex OPFS operations are skipped due to the difficulty of mocking the OPFS API)
-
-- **S3CompatibleStorage and R2Storage**
-  - Basic structure for testing is provided but skipped by default as they require actual credentials
-  - These tests serve as documentation for how to test these storage types if needed
-
-#### Environment Detection
-
-- **Forced Storage Types**
-  - Selecting MemoryStorage when forceMemoryStorage is true
-  - Selecting FileSystemStorage when forceFileSystemStorage is true
-
-- **Specific Storage Types**
-  - Selecting MemoryStorage when type is memory
-  - Selecting FileSystemStorage when type is filesystem
-
-- **Auto-detection**
-  - Selecting FileSystemStorage in Node.js environment
-  - Selecting OPFS in browser environment if available
-  - Falling back to MemoryStorage when OPFS is not available in browser
-
-### Mock Implementations for Testing
-
-To facilitate testing of storage adapters in different environments, we've created mock implementations for both OPFS and S3 compatible storage:
-
-#### OPFS Mock
-
-The OPFS (Origin Private File System) mock implementation provides a simulated file system environment for testing OPFS storage in a Node.js environment without requiring actual browser APIs. It's located in `/tests/mocks/opfs-mock.ts` and includes:
-
-- A mock file system using Maps to store directories and files
-- Mock implementations of FileSystemDirectoryHandle and FileSystemFileHandle
-- Functions to set up and clean up the mock environment
-- Support for all OPFS operations used by the OPFSStorage adapter
-
-#### S3 Mock
-
-The S3 compatible storage mock implementation provides a simulated S3 bucket environment for testing S3 compatible storage in a Node.js environment without requiring actual S3 credentials. It's located in `/tests/mocks/s3-mock.ts` and includes:
-
-- A mock S3 storage using Maps to store buckets and objects
-- Mock implementations of S3 commands (CreateBucketCommand, PutObjectCommand, etc.)
-- Functions to set up and clean up the mock environment
-- Support for basic S3 operations used by the S3CompatibleStorage adapter
-
-### Running the Tests
-
-The storage tests can be run with:
-
-```bash
-# Run all storage tests
-npx vitest run tests/storage-adapters.test.ts
-
-# Run OPFS storage tests
-npx vitest run tests/opfs-storage.test.ts
-
-# Run S3 storage tests
-npx vitest run tests/s3-storage.test.ts
-```
-
-### Future Improvements
-
-1. **Increase Test Coverage**: Add more tests for specific methods of each storage adapter
-2. **Improve OPFS Testing**: Continue to enhance the OPFS mock implementation to better simulate browser environments
-3. **Enhance S3 Testing**: Improve the S3 mock implementation to fully support all operations used by the S3CompatibleStorage adapter
-4. **Integration Tests**: Add integration tests that test the storage system with real data
-5. **Browser Environment Testing**: Add tests that run in actual browser environments for OPFS storage
-6. **Real S3 Testing**: Add optional tests that can run against real S3 compatible services when credentials are provided
-
-## Test Matrix
-
-This section outlines a comprehensive testing strategy for the Brainy vector database, ensuring all functionality works correctly across different environments and configurations.
-
-### Test Dimensions
-
-The test matrix covers the following dimensions:
-
-1. **Public Methods**: All public methods of the BrainyData class
-2. **Storage Adapters**: All supported storage types
-3. **Environments**: All supported runtime environments
-4. **Test Types**: Happy path, error handling, edge cases, performance
-
-### Storage Adapters
-
-- Memory Storage
-- File System Storage
-- OPFS (Origin Private File System) Storage
-- S3-Compatible Storage (including R2)
-
-### Environments
-
-- Node.js
-- Browser
-- Web Worker
-- Worker Threads
-
-### Test Types
-
-- **Happy Path**: Tests with valid inputs and expected behavior
-- **Error Handling**: Tests with invalid inputs, error conditions
-- **Edge Cases**: Tests with boundary values, empty inputs, etc.
-- **Performance**: Tests measuring execution time with various dataset sizes
-
-### Core Method Test Matrix
-
-| Method | Memory | FileSystem | OPFS | S3 | Error Handling | Edge Cases | Performance |
-|--------|--------|------------|------|----|--------------------|------------|-------------|
-| init() | ✅ | ✅ | ⚠️ | ⚠️ | ⚠️ | ⚠️ | ❌ |
-| add() | ✅ | ✅ | ⚠️ | ❌ | ⚠️ | ⚠️ | ❌ |
-| addBatch() | ✅ | ✅ | ❌ | ❌ | ⚠️ | ❌ | ❌ |
-| search() | ✅ | ✅ | ⚠️ | ❌ | ⚠️ | ⚠️ | ❌ |
-| searchText() | ✅ | ✅ | ❌ | ❌ | ⚠️ | ❌ | ❌ |
-| get() | ✅ | ✅ | ❌ | ❌ | ⚠️ | ❌ | ❌ |
-| delete() | ✅ | ✅ | ❌ | ❌ | ⚠️ | ❌ | ❌ |
-| updateMetadata() | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
-| relate() | ⚠️ | ⚠️ | ❌ | ❌ | ❌ | ❌ | ❌ |
-| findSimilar() | ⚠️ | ⚠️ | ❌ | ❌ | ❌ | ❌ | ❌ |
-| clear() | ✅ | ✅ | ⚠️ | ❌ | ❌ | ❌ | ❌ |
-| isReadOnly()/setReadOnly() | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
-| getStatistics() | ⚠️ | ⚠️ | ❌ | ❌ | ❌ | ❌ | ❌ |
-| backup()/restore() | ⚠️ | ⚠️ | ❌ | ❌ | ❌ | ❌ | ❌ |
-
-Legend:
-- ✅ Well tested
-- ⚠️ Partially tested
-- ❌ Not tested
-
-### Environment Test Matrix
-
-| Environment | Memory | FileSystem | OPFS | S3 |
-|-------------|--------|------------|------|-----|
-| Node.js | ✅ | ✅ | N/A | ⚠️ |
-| Browser | ⚠️ | N/A | ⚠️ | ❌ |
-| Web Worker | ❌ | N/A | ❌ | ❌ |
-| Worker Threads | ❌ | ⚠️ | N/A | ❌ |
-
-### Testing Gaps to Address
-
-1. **Error handling scenarios** for each method
-   - Invalid inputs
-   - Network failures
-   - Storage failures
-   - Concurrent operation conflicts
-
-2. **Edge cases**
-   - Empty queries
-   - Invalid IDs
-   - Maximum size datasets
-   - Zero-length vectors
-   - Dimension mismatches
-
-3. **Different storage adapters**
-   - Complete OPFS testing
-   - Complete S3 testing
-   - Test adapter switching/fallback
-
-4. **Multi-environment behavior**
-   - Browser-specific tests
-   - Web Worker tests
-   - Worker Threads tests
-
-5. **Read-only mode enforcement**
-   - Test all write operations in read-only mode
-
-6. **Relationship operations**
-   - Complete testing for relate()
-   - Complete testing for findSimilar()
-
-7. **Metadata handling**
-   - Test metadata in add/relate operations
-   - Test updateMetadata edge cases
-
-8. **Large dataset operations**
-   - Performance with 10k+ vectors
-   - Memory usage optimization
-
-9. **Concurrent operations**
-   - Thread safety
-   - Race condition handling
-
-10. **Statistics and monitoring**
-    - Accuracy of statistics
-    - Performance impact of statistics tracking
-
-### Implementation Plan
-
-1. Create error handling tests for core methods
-2. Create edge case tests for core methods
-3. Complete storage adapter tests for OPFS and S3
-4. Create environment-specific test suites
-5. Implement read-only mode tests
-6. Complete relationship operation tests
-7. Create metadata handling tests
-8. Implement performance tests with various dataset sizes
-9. Create concurrent operation tests
-10. Complete statistics and monitoring tests
-
-## API Integration Test Troubleshooting
-
-This section describes a specific issue with the API integration test and how it was resolved.
-
-### Issue Summary
-The API integration test was failing because it was trying to insert data into Brainy and then search for it, but the data wasn't being properly embedded/vectorized or wasn't being found in the search results.
-
-### Key Changes That Fixed the Issue
-
-#### Test Modifications
-1. Removed the explicit `dimensions: 512` parameter from BrainyData initialization
-   - This allows it to use the default dimensions that match the embedding model
-
-2. Changed from using `addItem()` to using `add()` with `forceEmbed: true`
-   - This ensures proper embedding of the text data
-
-3. Increased the wait time for indexing from 500ms to 2000ms
-   - Gives the HNSW index more time to update before searching
-
-4. Added more detailed logging to help diagnose issues
-
-#### Embedding Functionality Improvements
-1. Fixed how the Universal Sentence Encoder is loaded
-   - Now ensures it uses the bundled model from the package
-
-2. Improved type handling for TextDecoder to avoid potential compatibility issues
-
-### Why It Works Now
-The test is now passing because:
-1. The data is being properly embedded through the `add()` method with forced embedding
-2. The system has enough time to index the data before searching for it
-3. The embedding model is being loaded correctly without dimension mismatches
-
-These changes ensure that when data is inserted into Brainy, it's properly embedded and vectorized, and then can be successfully retrieved through semantic search without needing to run in Express or any other server environment.
-
-## Testing Best Practices
-
-When developing and debugging Brainy, follow these testing guidelines:
-
-1. **Use Proper Test Files**: All tests should be written as vitest test files in the `tests/` directory with `.test.ts` or `.spec.ts` extensions.
-
-2. **Avoid Temporary Debug Files**: Do not create temporary debug files like `debug_test.js`, `reproduce_issue.js`, or similar files in the root directory. These files:
-   - Clutter the repository
-   - Are excluded by vitest configuration but remain in the codebase
-   - Often duplicate functionality already covered by proper tests
-
-3. **Debugging Approach**: When debugging issues:
-   - Add temporary test cases to existing test files in the `tests/` directory
-   - Use `it.only()` or `describe.only()` to focus on specific tests during debugging
-   - Remove or convert temporary test cases to permanent tests before committing
-   - Use the existing test setup and utilities in `tests/setup.ts`
-
-4. **Test Organization**: 
-   - Core functionality tests go in `tests/core.test.ts`
-   - Environment-specific tests go in `tests/environment.*.test.ts`
-   - Utility function tests go in `tests/vector-operations.test.ts`
-   - New feature tests should follow the existing naming convention
-
-5. **Cleanup**: Always clean up temporary files before committing. The vitest configuration already excludes `*.js` files in the root directory, but they should be deleted rather than left in the repository.
-
-6. **Test Reporting**: Use the comprehensive test reporting feature when you need detailed information about test execution:
-   - Run `npm run test:report` to get a verbose report of all tests
-   - The report includes test names, execution time, and pass/fail status
-   - This is especially useful for CI/CD pipelines and debugging test failures

THREADING.md

@@ -1,183 +0,0 @@
-# Brainy Threading Implementation
-
-This document explains how Brainy's threading implementation works across different environments.
-
-## Overview
-
-Brainy uses a unified threading approach that adapts to the environment it's running in:
-
-1. **Node.js**: Uses Worker Threads API (optimized for Node.js 24+)
-2. **Browser**: Uses Web Workers API
-3. **Fallback**: Executes on the main thread when neither Worker Threads nor Web Workers are available
-
-This implementation ensures that compute-intensive operations (like embedding generation and vector calculations) can be performed efficiently without blocking the main thread, while maintaining compatibility across all environments.
-
-## Implementation Details
-
-### Environment Detection
-
-Brainy automatically detects the environment it's running in:
-
-```typescript
-// From unified.ts
-export const environment = {
-  isBrowser: typeof window !== 'undefined',
-  isNode: typeof process !== 'undefined' && process.versions && process.versions.node,
-  isServerless: typeof window === 'undefined' && 
-    (typeof process === 'undefined' || !process.versions || !process.versions.node)
-}
-```
-
-Additional environment detection functions are available in `src/utils/environment.ts`:
-
-```typescript
-// Check if threading is available
-export function isThreadingAvailable(): boolean {
-  return areWebWorkersAvailable() || areWorkerThreadsAvailable();
-}
-
-// Check if Web Workers are available (browser)
-export function areWebWorkersAvailable(): boolean {
-  return isBrowser() && typeof Worker !== 'undefined';
-}
-
-// Check if Worker Threads are available (Node.js)
-export function areWorkerThreadsAvailable(): boolean {
-  if (!isNode()) return false;
-  try {
-    require('worker_threads');
-    return true;
-  } catch (e) {
-    return false;
-  }
-}
-```
-
-### Thread Execution
-
-The core of the threading implementation is the `executeInThread` function in `src/utils/workerUtils.ts`:
-
-```typescript
-export function executeInThread<T>(fnString: string, args: any): Promise<T> {
-  if (environment.isNode) {
-    return executeInNodeWorker<T>(fnString, args)
-  } else if (environment.isBrowser && typeof window !== 'undefined' && window.Worker) {
-    return executeInWebWorker<T>(fnString, args)
-  } else {
-    // Fallback to main thread execution
-    try {
-      const fn = new Function('return ' + fnString)()
-      return Promise.resolve(fn(args) as T)
-    } catch (error) {
-      return Promise.reject(error)
-    }
-  }
-}
-```
-
-This function:
-1. Checks if it's running in Node.js and uses Worker Threads if available
-2. Checks if it's running in a browser and uses Web Workers if available
-3. Falls back to executing on the main thread if neither is available
-
-### Node.js Implementation
-
-For Node.js environments, Brainy uses the Worker Threads API with optimizations for Node.js 24:
-
-```typescript
-function executeInNodeWorker<T>(fnString: string, args: any): Promise<T> {
-  // Implementation using Node.js Worker Threads
-  // Includes worker pool management for better performance
-  // Uses dynamic imports with the 'node:' protocol prefix
-  // ...
-}
-```
-
-Key optimizations:
-- Worker pool to reuse workers and minimize overhead
-- Dynamic imports with the `node:` protocol prefix
-- Error handling and cleanup
-
-### Browser Implementation
-
-For browser environments, Brainy uses the Web Workers API:
-
-```typescript
-function executeInWebWorker<T>(fnString: string, args: any): Promise<T> {
-  // Implementation using browser Web Workers
-  // Creates a blob URL for the worker code
-  // Handles message passing and error handling
-  // ...
-}
-```
-
-Key features:
-- Creates workers using Blob URLs
-- Proper cleanup of resources (terminating workers and revoking URLs)
-- Error handling
-
-### Fallback Mechanism
-
-When neither Worker Threads nor Web Workers are available, Brainy falls back to executing on the main thread:
-
-```typescript
-// Fallback to main thread execution
-try {
-  const fn = new Function('return ' + fnString)()
-  return Promise.resolve(fn(args) as T)
-} catch (error) {
-  return Promise.reject(error)
-}
-```
-
-This ensures that Brainy works in all environments, even if threading is not available.
-
-## Usage
-
-The threading implementation is used throughout Brainy, particularly for compute-intensive operations like embedding generation:
-
-```typescript
-export function createThreadedEmbeddingFunction(
-  model: EmbeddingModel
-): EmbeddingFunction {
-  const embeddingFunction = createEmbeddingFunction(model)
-
-  return async (data: any): Promise<Vector> => {
-    // Convert the embedding function to a string
-    const fnString = embeddingFunction.toString()
-
-    // Execute the embedding function in a thread
-    return await executeInThread<Vector>(fnString, data)
-  }
-}
-```
-
-## Testing
-
-Two test scripts are provided to verify the threading implementation:
-
-1. `demo/test-browser-worker.html`: Tests the threading implementation in a browser environment
-2. `demo/test-fallback.html`: Tests the fallback mechanism when threading is not available
-
-To run these tests:
-1. Build the project: `npm run build`
-2. Start a local server: `npx http-server`
-3. Open the test pages in a browser:
-   - http://localhost:8080/demo/test-browser-worker.html
-   - http://localhost:8080/demo/test-fallback.html
-
-## Compatibility
-
-The threading implementation has been tested and works in:
-
-- Node.js 24+ (using Worker Threads)
-- Modern browsers (using Web Workers):
-  - Chrome
-  - Firefox
-  - Safari
-  - Edge
-- Environments without threading support (using fallback mechanism)
-
-## Conclusion
-
-Brainy's threading implementation provides efficient execution of compute-intensive operations across all environments, with optimizations for Node.js 24 and modern browsers, and a fallback mechanism for environments where threading is not available.

USE_MODEL_LOADING_EXPLANATION.md

@@ -1,75 +0,0 @@
-# Universal Sentence Encoder Model Loading Explanation
-
-## Overview
-
-This document explains how the Universal Sentence Encoder (USE) model is loaded in the `embedding.ts` file and why fallback mechanisms are necessary.
-
-## Default Model Source
-
-The Universal Sentence Encoder model is **not bundled with the npm package**. Instead, it is loaded from external sources by default:
-
-1. The TensorFlow.js implementation of Universal Sentence Encoder (`@tensorflow-models/universal-sentence-encoder`) is designed to load the model from TensorFlow Hub by default.
-
-2. In the original package implementation (as seen in `node_modules/@tensorflow-models/universal-sentence-encoder/dist/universal-sentence-encoder.js`), the default model URL is:
-   ```
-   https://tfhub.dev/tensorflow/tfjs-model/universal-sentence-encoder-lite/1/default/1
-   ```
-
-3. The vocabulary file is loaded from:
-   ```
-   https://storage.googleapis.com/tfjs-models/savedmodel/universal_sentence_encoder/vocab.json
-   ```
-
-## Why Fallback Mechanisms Exist
-
-The fallback mechanisms in `embedding.ts` exist because loading models from external sources can fail for various reasons:
-
-1. **Network Connectivity Issues**: If the application is offline or has limited connectivity, it may not be able to access the model from TensorFlow Hub.
-
-2. **Server Availability**: If the TensorFlow Hub server is down or experiencing issues, the model may not be accessible.
-
-3. **Rate Limiting or Throttling**: If too many requests are made to TensorFlow Hub, some requests may be rejected.
-
-4. **Firewall or Proxy Restrictions**: In some environments, outbound connections to TensorFlow Hub may be blocked.
-
-5. **CDN Caching Issues**: Content delivery networks may have stale or corrupted cached versions of the model.
-
-## Fallback Implementation
-
-The `loadModelWithRetry` function in `embedding.ts` implements the following fallback strategy:
-
-1. First, it tries to load the model using the original load function (which uses the default URL from the package).
-
-2. If that fails, it retries up to `maxRetries` times (default: 3) with exponential backoff.
-
-3. If all retries fail, it tries alternative URLs:
-   ```javascript
-   const alternativeUrls = [
-     'https://storage.googleapis.com/tfjs-models/savedmodel/universal_sentence_encoder/model.json',
-     'https://tfhub.dev/tensorflow/tfjs-model/universal-sentence-encoder/1/default/1',
-     'https://tfhub.dev/tensorflow/universal-sentence-encoder/4'
-   ]
-   ```
-
-## Why Would It Fail When Local to the Package?
-
-The question "Why would it ever fail when it is local to the package?" is based on a misunderstanding. The model is **not** local to the package. The npm package only contains the JavaScript code to load and use the model, but the actual model weights (which can be several megabytes) are stored externally and loaded at runtime.
-
-This approach has several advantages:
-- Reduces the package size significantly
-- Allows for model updates without requiring package updates
-- Enables sharing of model weights across different applications
-
-However, it also introduces the dependency on external resources, which is why fallback mechanisms are necessary.
-
-## Recommendations
-
-If reliable offline operation is required, consider:
-
-1. **Caching the model**: TensorFlow.js has built-in model caching capabilities that can be leveraged.
-
-2. **Bundling the model**: For critical applications, you could download the model files and host them alongside your application.
-
-3. **Implementing more robust fallbacks**: Add more alternative sources or implement a more sophisticated retry strategy.
-
-4. **Monitoring model loading**: Add telemetry to track model loading success rates and failures to identify issues early.

VECTOR_DIMENSION_STANDARDIZATION.md

@@ -1,59 +0,0 @@
-# Vector Dimension Standardization
-
-## Overview
-
-As of version 0.18.0, Brainy has standardized all vector dimensions to 512, which is the dimension used by the Universal Sentence Encoder. This change ensures consistency between data insertion, storage, and search operations, eliminating potential dimension mismatch issues.
-
-## Changes Made
-
-1. **Fixed Dimension Value**: Vector dimensions are now fixed at 512 throughout the codebase.
-2. **Removed Configuration Option**: The `dimensions` configuration option has been removed from `BrainyDataConfig`.
-3. **Consistent Validation**: All vectors are validated to ensure they have exactly 512 dimensions.
-
-## Rationale
-
-Previously, vector dimensions were configurable, which could lead to mismatches between:
-- Vectors stored in the database
-- The expected dimensions in the HNSW index
-- Vectors generated by the embedding function
-
-These mismatches could cause search functionality to break, as vectors with different dimensions would be skipped during initialization.
-
-By standardizing all vectors to 512 dimensions (matching the Universal Sentence Encoder's output), we ensure that:
-- All vectors in the database have consistent dimensions
-- The HNSW index always works with vectors of the expected size
-- Search queries always match the dimension of stored vectors
-
-## Impact on Existing Code
-
-### Breaking Changes
-
-- The `dimensions` property in `BrainyDataConfig` has been removed
-- Attempting to add vectors with dimensions other than 512 will throw an error
-- Existing data with non-512 dimensions will be skipped during initialization
-
-### Migration
-
-If you have existing data with dimensions other than 512, you can use the provided `fix-dimension-mismatch.js` script to re-embed your data with the correct dimensions:
-
-```bash
-node fix-dimension-mismatch.js
-```
-
-This script:
-1. Creates a backup of your existing data
-2. Re-embeds all nouns using the Universal Sentence Encoder (512 dimensions)
-3. Recreates all verb relationships
-4. Verifies that search functionality works correctly
-
-## Best Practices
-
-- Always use the built-in embedding function for text data, which will automatically produce 512-dimensional vectors
-- If you're creating vectors manually, ensure they have exactly 512 dimensions
-- When migrating from previous versions, run the `fix-dimension-mismatch.js` script to ensure all data has consistent dimensions
-
-## Technical Details
-
-The Universal Sentence Encoder model produces 512-dimensional vectors by default. This is now the standard dimension for all vectors in Brainy, ensuring consistency across all operations.
-
-For more information about the dimension mismatch issue and its resolution, see `DIMENSION_MISMATCH_SUMMARY.md`.

VITEST_IMPROVEMENTS.md

@@ -1,226 +0,0 @@
-# Vitest Output Improvements
-
-## Changes Made
-
-The Vitest configuration has been updated to provide cleaner, more focused test output that shows only successes,
-failures, and a nice summary report at the end. The following changes were implemented:
-
-### 1. Reporter Configuration
-
-- Removed the verbose reporter which was causing excessive output
-- Configured the default reporter to:
-    - Show a summary at the end
-    - Display test titles for all tests
-    - Use a compact output format
-
-```javascript
-reporters: [
-  [
-    'default',
-    {
-      summary: true,
-      reportSummary: true,
-      successfulTestOnly: false,
-      outputFile: false
-    }
-  ]
-]
-```
-
-### 2. Output Settings
-
-- Set `hideSkippedTests: true` to reduce noise from skipped tests
-- Set `printConsoleTrace: false` to only show stack traces for failed tests
-- Added output formatting options:
-  ```javascript
-  outputDiffLines: 5;      // Limit diff output lines for cleaner error reports
-  outputFileMaxLines: 40;  // Limit file output lines for cleaner error reports
-  outputTruncateLength: 80; // Truncate long output lines
-  ```
-
-### 3. Console Output Filtering
-
-Enhanced the `onConsoleLog` function to be more aggressive in filtering out unnecessary output:
-
-- Added filtering for stdout logs to only show errors, failures, warnings, and test results
-- Expanded the noise patterns list to filter out more common noise sources
-- Added explicit handling to show logs that pass all filters
-
-## Results
-
-The test output is now much cleaner and more focused:
-
-1. Only shows important information like test successes and failures
-2. Displays stderr messages only when relevant (e.g., for error handling tests)
-3. Provides a clean, readable summary at the end showing:
-    - Number of test files passed
-    - Number of tests passed
-    - Duration information
-    - Start time
-
-## How to Run Tests
-
-Use the standard npm test commands:
-
-```bash
-# Run all tests
-npm test
-
-# Run specific test file
-npm test -- tests/core.test.ts
-
-# Run tests in watch mode
-npm run test:watch
-```
-
-## Recent Improvements (July 2025)
-
-The Vitest configuration has been further enhanced to provide more detailed reporting and better console output suppression:
-
-### 1. Multiple Reporters
-
-Added multiple reporters to provide different levels of detail:
-
-```javascript
-reporters: [
-  // Default reporter for basic progress and summary
-  [
-    'default',
-    {
-      summary: true,
-      reportSummary: true,
-      successfulTestOnly: false,
-      outputFile: false
-    }
-  ],
-  // Verbose reporter for detailed information about failures
-  [
-    'verbose',
-    {
-      onError: true,
-      displayDiff: true,
-      displayErrorStacktrace: true
-    }
-  ],
-  // JSON reporter for machine-readable output
-  [
-    'json',
-    {
-      outputFile: './test-results.json'
-    }
-  ]
-]
-```
-
-### 2. Enhanced Console Output Suppression
-
-Improved the console output filtering to be more aggressive:
-
-- Added a whitelist approach for stdout, only allowing specific test-related patterns
-- Enhanced stderr filtering to only show actual errors
-- Expanded the list of noise patterns to filter out common debug messages
-- Added additional filtering for common debug output patterns
-
-### 3. New Test Scripts
-
-Added several new test scripts to provide different reporting options:
-
-```bash
-# Standard test run with default configuration
-npm test
-
-# Detailed report with verbose output
-npm run test:report:detailed
-
-# Generate JSON report for machine processing
-npm run test:report:json
-
-# Run tests in silent mode (minimal output)
-npm run test:silent
-
-# Show only progress and errors
-npm run test:progress-only
-```
-
-## How to Use the New Features
-
-### For Detailed Test Reports
-
-When you need comprehensive information about test results, especially for failures:
-
-```bash
-npm run test:report:detailed
-```
-
-This will show detailed information about each test, including:
-- Full test hierarchy
-- Detailed error messages with stack traces
-- Test durations
-- Comprehensive summary
-
-### For CI/CD Integration
-
-When you need machine-readable output for integration with CI/CD systems:
-
-```bash
-npm run test:report:json
-```
-
-This generates a `test-results.json` file that can be processed by other tools.
-
-### For Minimal Output
-
-When you want to see only test progress without noise:
-
-```bash
-npm run test:progress-only
-```
-
-This shows only test progress indicators and critical errors.
-
-### For Completely Silent Operation
-
-When you want to run tests with minimal console output:
-
-```bash
-npm run test:silent
-```
-
-## Recent Improvements (July 2025)
-
-### Pretty Test Reporter
-
-A new visually appealing test summary reporter has been added to provide a clearer, more readable test summary. The pretty reporter:
-
-- Uses colors and symbols to distinguish between passed, failed, and skipped tests
-- Displays test results in a clean, tabular format
-- Shows detailed statistics about the test run
-- Clearly lists any failed tests with their error messages
-
-To use the pretty reporter, run:
-
-```bash
-npm run test:report:pretty
-```
-
-For more details, see the [PRETTY_TEST_REPORTER.md](./PRETTY_TEST_REPORTER.md) document.
-
-## Future Improvements
-
-If further customization is needed, consider:
-
-1. Creating custom HTML reports for better visualization
-2. Integrating with notification systems for test failures
-3. Adding performance benchmarking to the test reports
-
-## Recent Fixes (July 2025)
-
-### Fixed Duplicate Summary Output
-
-The test output was showing duplicate summary information at the end of test runs. This has been fixed by:
-
-1. Simplifying the reporters configuration to use only the necessary reporters
-2. Removing the verbose reporter which was causing duplicate summary output
-3. Keeping only the default reporter for console output and JSON reporter for machine-readable output
-
-For more information about expected error messages during test runs, see the [EXPECTED_TEST_MESSAGES.md](./EXPECTED_TEST_MESSAGES.md) document.

assets/models/all-MiniLM-L6-v2/config.json

@@ -0,0 +1,24 @@
+{
+  "_name_or_path": "nreimers/MiniLM-L6-H384-uncased",
+  "architectures": [
+    "BertModel"
+  ],
+  "attention_probs_dropout_prob": 0.1,
+  "gradient_checkpointing": false,
+  "hidden_act": "gelu",
+  "hidden_dropout_prob": 0.1,
+  "hidden_size": 384,
+  "initializer_range": 0.02,
+  "intermediate_size": 1536,
+  "layer_norm_eps": 1e-12,
+  "max_position_embeddings": 512,
+  "model_type": "bert",
+  "num_attention_heads": 12,
+  "num_hidden_layers": 6,
+  "pad_token_id": 0,
+  "position_embedding_type": "absolute",
+  "transformers_version": "4.8.2",
+  "type_vocab_size": 2,
+  "use_cache": true,
+  "vocab_size": 30522
+}

bin/brainy-interactive.js

@@ -0,0 +1,564 @@
+#!/usr/bin/env node
+
+/**
+ * Brainy Interactive Mode
+ * 
+ * Professional, guided CLI experience for beginners
+ */
+
+import { program } from 'commander'
+import { Brainy } from '../dist/index.js'
+import chalk from 'chalk'
+import inquirer from 'inquirer'
+import ora from 'ora'
+import Table from 'cli-table3'
+import boxen from 'boxen'
+
+// Professional color scheme
+const colors = {
+  primary: chalk.hex('#3A5F4A'),    // Teal (from logo)
+  success: chalk.hex('#2D4A3A'),    // Deep teal
+  info: chalk.hex('#4A6B5A'),       // Medium teal  
+  warning: chalk.hex('#D67441'),    // Orange (from logo)
+  error: chalk.hex('#B85C35'),      // Deep orange
+  brain: chalk.hex('#D67441'),      // Brain orange
+  cream: chalk.hex('#F5E6A3'),      // Cream background
+  dim: chalk.dim,
+  bold: chalk.bold,
+  cyan: chalk.cyan,
+  green: chalk.green,
+  yellow: chalk.yellow,
+  red: chalk.red
+}
+
+// Icons for consistent visual language
+const icons = {
+  brain: '🧠',
+  search: '🔍',
+  add: '➕',
+  delete: '🗑️',
+  update: '🔄',
+  import: '📥',
+  export: '📤',
+  connect: '🔗',
+  question: '❓',
+  success: '✅',
+  error: '❌',
+  warning: '⚠️',
+  info: 'ℹ️',
+  sparkle: '✨',
+  rocket: '🚀',
+  thinking: '🤔',
+  chat: '💬',
+  stats: '📊',
+  config: '⚙️',
+  cloud: '☁️'
+}
+
+let brainyInstance = null
+
+async function getBrainy() {
+  if (!brainyInstance) {
+    const spinner = ora('Initializing Brainy...').start()
+    try {
+      brainyInstance = new Brainy()
+      await brainyInstance.init()
+      spinner.succeed('Brainy initialized')
+    } catch (error) {
+      spinner.fail('Failed to initialize Brainy')
+      console.error(colors.error(error.message))
+      process.exit(1)
+    }
+  }
+  return brainyInstance
+}
+
+/**
+ * Professional welcome screen
+ */
+function showWelcome() {
+  console.clear()
+  
+  const welcomeBox = boxen(
+    colors.primary(`${icons.brain}  BRAINY - Neural Intelligence System\n`) +
+    colors.dim('\nYour AI-Powered Second Brain\n') +
+    colors.info('Version 1.6.0'),
+    {
+      padding: 1,
+      margin: 1,
+      borderStyle: 'round',
+      borderColor: 'cyan',
+      textAlignment: 'center'
+    }
+  )
+  
+  console.log(welcomeBox)
+  console.log()
+}
+
+/**
+ * Main interactive menu
+ */
+async function mainMenu() {
+  const { action } = await inquirer.prompt([{
+    type: 'list',
+    name: 'action',
+    message: colors.cyan('What would you like to do?'),
+    choices: [
+      new inquirer.Separator(colors.dim('── Core Operations ──')),
+      { name: `${icons.add}  Add data to your brain`, value: 'add' },
+      { name: `${icons.search}  Search your knowledge`, value: 'search' },
+      { name: `${icons.chat}  Chat with your data`, value: 'chat' },
+      { name: `${icons.update}  Update existing data`, value: 'update' },
+      { name: `${icons.delete}  Delete data`, value: 'delete' },
+      
+      new inquirer.Separator(colors.dim('── Advanced Features ──')),
+      { name: `${icons.connect}  Create relationships`, value: 'relate' },
+      { name: `${icons.import}  Import from file/URL`, value: 'import' },
+      { name: `${icons.export}  Export your brain`, value: 'export' },
+      { name: `${icons.brain}  Neural operations`, value: 'neural' },
+      
+      new inquirer.Separator(colors.dim('── System ──')),
+      { name: `${icons.stats}  View statistics`, value: 'stats' },
+      { name: `${icons.config}  Configuration`, value: 'config' },
+      { name: `${icons.cloud}  Brain Cloud`, value: 'cloud' },
+      { name: `${icons.info}  Help & Documentation`, value: 'help' },
+      
+      new inquirer.Separator(),
+      { name: 'Exit', value: 'exit' }
+    ],
+    pageSize: 20
+  }])
+  
+  return action
+}
+
+/**
+ * Neural operations submenu
+ */
+async function neuralMenu() {
+  const { operation } = await inquirer.prompt([{
+    type: 'list',
+    name: 'operation',
+    message: colors.cyan('Select neural operation:'),
+    choices: [
+      { name: `${icons.brain}  Calculate similarity`, value: 'similar' },
+      { name: `${icons.search}  Find clusters`, value: 'cluster' },
+      { name: `${icons.connect}  Find related items`, value: 'related' },
+      { name: `${icons.thinking}  Build hierarchy`, value: 'hierarchy' },
+      { name: `${icons.rocket}  Find semantic path`, value: 'path' },
+      { name: `${icons.warning}  Detect outliers`, value: 'outliers' },
+      { name: `${icons.sparkle}  Generate visualization`, value: 'visualize' },
+      new inquirer.Separator(),
+      { name: '← Back to main menu', value: 'back' }
+    ]
+  }])
+  
+  return operation
+}
+
+/**
+ * Execute commands with beautiful feedback
+ */
+async function executeCommand(command) {
+  const brain = await getBrainy()
+  
+  switch (command) {
+    case 'add':
+      await interactiveAdd(brain)
+      break
+      
+    case 'search':
+      await interactiveSearch(brain)
+      break
+      
+    case 'chat':
+      await interactiveChat(brain)
+      break
+      
+    case 'update':
+      await interactiveUpdate(brain)
+      break
+      
+    case 'delete':
+      await interactiveDelete(brain)
+      break
+      
+    case 'relate':
+      await interactiveRelate(brain)
+      break
+      
+    case 'import':
+      await interactiveImport(brain)
+      break
+      
+    case 'export':
+      await interactiveExport(brain)
+      break
+      
+    case 'neural':
+      const neuralOp = await neuralMenu()
+      if (neuralOp !== 'back') {
+        await executeNeuralOperation(neuralOp, brain)
+      }
+      break
+      
+    case 'stats':
+      await showStatistics(brain)
+      break
+      
+    case 'config':
+      await interactiveConfig(brain)
+      break
+      
+    case 'cloud':
+      await showCloudInfo()
+      break
+      
+    case 'help':
+      await showHelp()
+      break
+  }
+}
+
+/**
+ * Interactive add with rich prompts
+ */
+async function interactiveAdd(brain) {
+  console.log(colors.primary(`\n${icons.add} Add Data\n`))
+  
+  const { inputType } = await inquirer.prompt([{
+    type: 'list',
+    name: 'inputType',
+    message: 'How would you like to add data?',
+    choices: [
+      { name: 'Type or paste text', value: 'text' },
+      { name: 'Multi-line editor', value: 'editor' },
+      { name: 'JSON object', value: 'json' },
+      { name: 'Import from clipboard', value: 'clipboard' }
+    ]
+  }])
+  
+  let data = ''
+  
+  switch (inputType) {
+    case 'text':
+      const { text } = await inquirer.prompt([{
+        type: 'input',
+        name: 'text',
+        message: 'Enter your data:',
+        validate: input => input.trim() ? true : 'Please enter some data'
+      }])
+      data = text
+      break
+      
+    case 'editor':
+      const { editorText } = await inquirer.prompt([{
+        type: 'editor',
+        name: 'editorText',
+        message: 'Enter your data (opens editor):',
+        postfix: '.md'
+      }])
+      data = editorText
+      break
+      
+    case 'json':
+      const { jsonText } = await inquirer.prompt([{
+        type: 'editor',
+        name: 'jsonText',
+        message: 'Enter JSON data:',
+        postfix: '.json',
+        default: '{\n  \n}',
+        validate: input => {
+          try {
+            JSON.parse(input)
+            return true
+          } catch (e) {
+            return `Invalid JSON: ${e.message}`
+          }
+        }
+      }])
+      data = jsonText
+      break
+  }
+  
+  // Optional metadata
+  const { addMetadata } = await inquirer.prompt([{
+    type: 'confirm',
+    name: 'addMetadata',
+    message: 'Would you like to add metadata?',
+    default: false
+  }])
+  
+  let metadata = {}
+  if (addMetadata) {
+    const { metadataJson } = await inquirer.prompt([{
+      type: 'editor',
+      name: 'metadataJson',
+      message: 'Enter metadata (JSON):',
+      postfix: '.json',
+      default: '{\n  "type": "",\n  "tags": [],\n  "category": ""\n}',
+      validate: input => {
+        try {
+          JSON.parse(input)
+          return true
+        } catch (e) {
+          return `Invalid JSON: ${e.message}`
+        }
+      }
+    }])
+    metadata = JSON.parse(metadataJson)
+  }
+  
+  const spinner = ora('Adding data...').start()
+  try {
+    const id = await brain.add(data, metadata)
+    spinner.succeed(`Added successfully with ID: ${id}`)
+    
+    // Show summary
+    console.log(boxen(
+      colors.success(`${icons.success} Data added successfully!\n\n`) +
+      colors.info(`ID: ${id}\n`) +
+      colors.dim(`Size: ${data.length} characters\n`) +
+      (Object.keys(metadata).length > 0 ? colors.dim(`Metadata: ${Object.keys(metadata).join(', ')}`) : ''),
+      { padding: 1, borderColor: 'green', borderStyle: 'round' }
+    ))
+  } catch (error) {
+    spinner.fail('Failed to add data')
+    console.error(colors.error(error.message))
+  }
+}
+
+/**
+ * Interactive search with filters
+ */
+async function interactiveSearch(brain) {
+  console.log(colors.primary(`\n${icons.search} Search\n`))
+  
+  const { query } = await inquirer.prompt([{
+    type: 'input',
+    name: 'query',
+    message: 'Enter search query:',
+    validate: input => input.trim() ? true : 'Please enter a search query'
+  }])
+  
+  // Advanced options
+  const { useFilters } = await inquirer.prompt([{
+    type: 'confirm',
+    name: 'useFilters',
+    message: 'Apply filters?',
+    default: false
+  }])
+  
+  let searchOptions = { limit: 10 }
+  
+  if (useFilters) {
+    const { limit, threshold } = await inquirer.prompt([
+      {
+        type: 'number',
+        name: 'limit',
+        message: 'Maximum results:',
+        default: 10
+      },
+      {
+        type: 'number',
+        name: 'threshold',
+        message: 'Similarity threshold (0-1):',
+        default: 0.5,
+        validate: input => input >= 0 && input <= 1 ? true : 'Must be between 0 and 1'
+      }
+    ])
+    
+    searchOptions.limit = limit
+    searchOptions.threshold = threshold
+  }
+  
+  const spinner = ora('Searching...').start()
+  try {
+    const results = await brain.search(query, searchOptions.limit, searchOptions)
+    spinner.succeed(`Found ${results.length} results`)
+    
+    if (results.length === 0) {
+      console.log(colors.warning('No results found'))
+    } else {
+      // Display results in a table
+      const table = new Table({
+        head: [colors.cyan('ID'), colors.cyan('Content'), colors.cyan('Score')],
+        style: { head: [], border: [] },
+        colWidths: [20, 50, 10]
+      })
+      
+      results.forEach(result => {
+        const content = result.content || result.id
+        const truncated = content.length > 47 ? content.substring(0, 47) + '...' : content
+        const score = result.score ? `${(result.score * 100).toFixed(1)}%` : 'N/A'
+        
+        table.push([
+          result.id.substring(0, 18),
+          truncated,
+          colors.green(score)
+        ])
+      })
+      
+      console.log(table.toString())
+      
+      // Ask if user wants to see full details
+      const { viewDetails } = await inquirer.prompt([{
+        type: 'confirm',
+        name: 'viewDetails',
+        message: 'View full details of a result?',
+        default: false
+      }])
+      
+      if (viewDetails) {
+        const { selectedId } = await inquirer.prompt([{
+          type: 'list',
+          name: 'selectedId',
+          message: 'Select result:',
+          choices: results.map(r => ({
+            name: `${r.id} - ${r.content?.substring(0, 50)}...`,
+            value: r.id
+          }))
+        }])
+        
+        const selected = results.find(r => r.id === selectedId)
+        console.log(boxen(
+          colors.cyan('Full Details\n\n') +
+          colors.info(`ID: ${selected.id}\n\n`) +
+          `Content:\n${selected.content}\n\n` +
+          (selected.metadata ? `Metadata:\n${JSON.stringify(selected.metadata, null, 2)}` : ''),
+          { padding: 1, borderColor: 'cyan', borderStyle: 'round' }
+        ))
+      }
+    }
+  } catch (error) {
+    spinner.fail('Search failed')
+    console.error(colors.error(error.message))
+  }
+}
+
+/**
+ * Show statistics with beautiful formatting
+ */
+async function showStatistics(brain) {
+  const spinner = ora('Gathering statistics...').start()
+  
+  try {
+    const stats = brain.getStats()
+    spinner.succeed('Statistics loaded')
+    
+    console.log(boxen(
+      colors.primary(`${icons.stats} Database Statistics\n\n`) +
+      colors.info(`Total Items: ${colors.bold(stats.total || 0)}\n`) +
+      colors.info(`Nouns: ${stats.nounCount || 0}\n`) +
+      colors.info(`Relationships: ${stats.verbCount || 0}\n`) +
+      colors.info(`Metadata Records: ${stats.metadataCount || 0}\n\n`) +
+      colors.dim(`Memory Usage: ${(process.memoryUsage().heapUsed / 1024 / 1024).toFixed(1)} MB`),
+      { 
+        padding: 1, 
+        borderColor: 'blue', 
+        borderStyle: 'round',
+        textAlignment: 'left'
+      }
+    ))
+  } catch (error) {
+    spinner.fail('Failed to get statistics')
+    console.error(colors.error(error.message))
+  }
+}
+
+/**
+ * Show help with examples
+ */
+async function showHelp() {
+  console.log(boxen(
+    colors.primary(`${icons.info} Brainy Help\n\n`) +
+    colors.cyan('Common Commands:\n') +
+    colors.dim(`
+  brainy add "text"        Add data
+  brainy search "query"    Search your brain
+  brainy chat             Interactive AI chat
+  brainy status           View statistics
+  brainy help             This help menu
+  
+`) +
+    colors.cyan('Interactive Mode:\n') +
+    colors.dim(`
+  brainy                  Start interactive mode
+  brainy -i               Alternative interactive mode
+  
+`) +
+    colors.cyan('Advanced Features:\n') +
+    colors.dim(`
+  brainy similar a b      Calculate similarity
+  brainy cluster          Find semantic clusters
+  brainy export           Export your data
+  brainy cloud            Brain Cloud features
+`),
+    { padding: 1, borderColor: 'yellow', borderStyle: 'round' }
+  ))
+  
+  const { learnMore } = await inquirer.prompt([{
+    type: 'confirm',
+    name: 'learnMore',
+    message: 'View detailed documentation?',
+    default: false
+  }])
+  
+  if (learnMore) {
+    console.log(colors.info('\nDocumentation: https://github.com/TimeSoul/brainy'))
+    console.log(colors.info('Enterprise features: Coming in future releases'))
+  }
+}
+
+/**
+ * Main interactive loop
+ */
+async function main() {
+  showWelcome()
+  
+  let running = true
+  while (running) {
+    const action = await mainMenu()
+    
+    if (action === 'exit') {
+      console.log(colors.success(`\n${icons.success} Thank you for using Brainy!\n`))
+      running = false
+    } else {
+      await executeCommand(action)
+      
+      // Pause before returning to menu
+      await inquirer.prompt([{
+        type: 'input',
+        name: 'continue',
+        message: colors.dim('\nPress Enter to continue...'),
+        prefix: ''
+      }])
+    }
+  }
+  
+  process.exit(0)
+}
+
+// Handle errors gracefully
+process.on('unhandledRejection', (error) => {
+  console.error(colors.error(`\n${icons.error} Unexpected error:`))
+  console.error(colors.red(error.message))
+  process.exit(1)
+})
+
+// Handle Ctrl+C gracefully
+process.on('SIGINT', () => {
+  console.log(colors.info(`\n\n${icons.info} Exiting Brainy...`))
+  process.exit(0)
+})
+
+// Run if called directly
+if (import.meta.url === `file://${process.argv[1]}`) {
+  main().catch(error => {
+    console.error(colors.error('Fatal error:'), error)
+    process.exit(1)
+  })
+}
+
+export { main as startInteractiveMode }

bin/brainy-minimal.js

@@ -0,0 +1,82 @@
+#!/usr/bin/env node
+
+/**
+ * Brainy CLI - Minimal Version (Conversation Commands Only)
+ *
+ * This is a temporary minimal CLI that only includes working conversation commands
+ * Full CLI will be restored in version 3.20.0
+ */
+
+import { Command } from 'commander'
+import { readFileSync } from 'fs'
+import { dirname, join } from 'path'
+import { fileURLToPath } from 'url'
+
+const __dirname = dirname(fileURLToPath(import.meta.url))
+const packageJson = JSON.parse(readFileSync(join(__dirname, '..', 'package.json'), 'utf8'))
+
+const program = new Command()
+
+program
+  .name('brainy')
+  .description('🧠 Brainy - Infinite Agent Memory')
+  .version(packageJson.version)
+
+// Dynamically load conversation command
+const conversationCommand = await import('../dist/cli/commands/conversation.js').then(m => m.default)
+
+program
+  .command('conversation')
+  .alias('conv')
+  .description('💬 Infinite agent memory and context management')
+  .addCommand(
+    new Command('setup')
+      .description('Set up MCP server for Claude Code integration')
+      .action(async () => {
+        await conversationCommand.handler({ action: 'setup', _: [] })
+      })
+  )
+  .addCommand(
+    new Command('remove')
+      .description('Remove MCP server and clean up')
+      .action(async () => {
+        await conversationCommand.handler({ action: 'remove', _: [] })
+      })
+  )
+  .addCommand(
+    new Command('search')
+      .description('Search messages across conversations')
+      .requiredOption('-q, --query <query>', 'Search query')
+      .option('-c, --conversation-id <id>', 'Filter by conversation')
+      .option('-r, --role <role>', 'Filter by role')
+      .option('-l, --limit <number>', 'Maximum results', '10')
+      .action(async (options) => {
+        await conversationCommand.handler({ action: 'search', ...options, _: [] })
+      })
+  )
+  .addCommand(
+    new Command('context')
+      .description('Get relevant context for a query')
+      .requiredOption('-q, --query <query>', 'Context query')
+      .option('-l, --limit <number>', 'Maximum messages', '10')
+      .action(async (options) => {
+        await conversationCommand.handler({ action: 'context', ...options, _: [] })
+      })
+  )
+  .addCommand(
+    new Command('thread')
+      .description('Get full conversation thread')
+      .requiredOption('-c, --conversation-id <id>', 'Conversation ID')
+      .action(async (options) => {
+        await conversationCommand.handler({ action: 'thread', ...options, _: [] })
+      })
+  )
+  .addCommand(
+    new Command('stats')
+      .description('Show conversation statistics')
+      .action(async () => {
+        await conversationCommand.handler({ action: 'stats', _: [] })
+      })
+  )
+
+program.parse(process.argv)

bin/brainy-ts.js

@@ -0,0 +1,18 @@
+#!/usr/bin/env node
+
+/**
+ * Modern TypeScript CLI Runner
+ * 
+ * This is the entry point after npm install @soulcraft/brainy
+ * It runs the compiled TypeScript CLI code
+ */
+
+// Use the compiled TypeScript CLI
+import('../dist/cli/index.js').catch(err => {
+  // Fallback to legacy CLI if new one isn't built yet
+  import('./brainy.js').catch(() => {
+    console.error('Error: CLI not properly built. Please reinstall the package.')
+    console.error(err)
+    process.exit(1)
+  })
+})

bin/brainy.js

@@ -0,0 +1,14 @@
+#!/usr/bin/env node
+
+/**
+ * Brainy CLI Wrapper
+ *
+ * Imports the compiled TypeScript CLI from dist/cli/index.js
+ * This ensures TypeScript features work correctly
+ */
+
+import('../dist/cli/index.js').catch((error) => {
+  console.error('Failed to load Brainy CLI:', error.message)
+  console.error('Make sure you have built the project: npm run build')
+  process.exit(1)
+})

check-database.js

@@ -1,83 +0,0 @@
-// Script to check if there's any data in the database
-import { BrainyData } from './dist/brainyData.js';
-
-async function checkDatabase() {
-  try {
-    console.log('Initializing BrainyData...');
-    const db = new BrainyData();
-    await db.init();
-    
-    console.log('Getting database status...');
-    const status = await db.status();
-    console.log('Database status:', JSON.stringify(status, null, 2));
-    
-    console.log('Getting statistics...');
-    const stats = await db.getStatistics();
-    console.log('Statistics:', JSON.stringify(stats, null, 2));
-    
-    console.log('Getting all nouns...');
-    const nouns = await db.getAllNouns();
-    console.log(`Found ${nouns.length} nouns in the database.`);
-    
-    if (nouns.length > 0) {
-      console.log('Sample of nouns:');
-      for (let i = 0; i < Math.min(5, nouns.length); i++) {
-        console.log(`Noun ${i + 1}:`, JSON.stringify(nouns[i], null, 2));
-      }
-    }
-    
-    console.log('Getting all verbs...');
-    const verbs = await db.getAllVerbs();
-    console.log(`Found ${verbs.length} verbs in the database.`);
-    
-    if (verbs.length > 0) {
-      console.log('Sample of verbs:');
-      for (let i = 0; i < Math.min(5, verbs.length); i++) {
-        console.log(`Verb ${i + 1}:`, JSON.stringify(verbs[i], null, 2));
-      }
-    }
-    
-    // Try a simple search to see if it returns any results
-    console.log('Trying a simple search...');
-    const searchResults = await db.searchText('test', 10);
-    console.log(`Search returned ${searchResults.length} results.`);
-    
-    if (searchResults.length > 0) {
-      console.log('Sample of search results:');
-      for (let i = 0; i < Math.min(5, searchResults.length); i++) {
-        console.log(`Result ${i + 1}:`, JSON.stringify({
-          id: searchResults[i].id,
-          score: searchResults[i].score,
-          metadata: searchResults[i].metadata
-        }, null, 2));
-      }
-    }
-    
-    // If no results, try adding a test item and searching again
-    if (searchResults.length === 0 && nouns.length === 0) {
-      console.log('No data found. Adding a test item...');
-      const id = await db.add('This is a test item for searching', { noun: 'Thing', category: 'test' });
-      console.log(`Added test item with ID: ${id}`);
-      
-      console.log('Trying search again...');
-      const newSearchResults = await db.searchText('test', 10);
-      console.log(`Search returned ${newSearchResults.length} results.`);
-      
-      if (newSearchResults.length > 0) {
-        console.log('Sample of search results:');
-        for (let i = 0; i < Math.min(5, newSearchResults.length); i++) {
-          console.log(`Result ${i + 1}:`, JSON.stringify({
-            id: newSearchResults[i].id,
-            score: newSearchResults[i].score,
-            metadata: newSearchResults[i].metadata
-          }, null, 2));
-        }
-      }
-    }
-    
-  } catch (error) {
-    console.error('Error checking database:', error);
-  }
-}
-
-checkDatabase().catch(console.error);

cli-package/README.md

@@ -1,54 +0,0 @@
-# @soulcraft/brainy-cli
-
-Command-line interface for the [Brainy vector graph database](https://github.com/soulcraft-research/brainy).
-
-## Installation
-
-```bash
-# Install globally
-npm install -g @soulcraft/brainy-cli
-```
-
-## Usage
-
-Once installed, you can use the `brainy` command from anywhere:
-
-```bash
-# Show help
-brainy --help
-
-# Initialize a new database
-brainy init
-
-# Add data
-brainy add "Cats are independent pets" '{"noun":"Thing","category":"animal"}'
-
-# Search
-brainy search "feline pets" --limit 5
-
-# Add relationships
-brainy addVerb id1 id2 RelatedTo '{"description":"Both are pets"}'
-
-# Visualize the graph
-brainy visualize
-brainy visualize --root <id> --depth 3
-
-# Generate random test data
-brainy generate-random-graph --noun-count 20 --verb-count 30 --clear
-```
-
-## Features
-
-- Full access to all Brainy database functionality from the command line
-- Autocomplete support for commands and options
-- Visualization of graph data
-- Import/export capabilities
-- Augmentation pipeline testing
-
-## Requirements
-
-- Node.js >= 24.4.0
-
-## License
-
-MIT

cli-package/brainy-wrapper.js

@@ -1,97 +0,0 @@
-#!/usr/bin/env node
-
-/**
- * Brainy CLI Wrapper
- * This script patches the global object to fix TextEncoder issues before loading the CLI
- */
-
-console.log('Brainy running in Node.js environment')
-
-// Define a custom PlatformNode class that doesn't rely on this.util.TextEncoder
-if (
-  typeof global !== 'undefined' &&
-  typeof process !== 'undefined' &&
-  process.versions &&
-  process.versions.node
-) {
-  try {
-    // Define a PlatformNode class that uses the global TextEncoder/TextDecoder directly
-    class PlatformNode {
-      constructor() {
-        // Create a util object with necessary methods
-        this.util = {
-          // Add isFloat32Array and isTypedArray directly to util
-          isFloat32Array: (arr) => {
-            return !!(
-              arr instanceof Float32Array ||
-              (arr &&
-                Object.prototype.toString.call(arr) === '[object Float32Array]')
-            )
-          },
-          isTypedArray: (arr) => {
-            return !!(ArrayBuffer.isView(arr) && !(arr instanceof DataView))
-          },
-          // Instead of using constructors directly, create a utility object with constructors
-          TextEncoder,
-          TextDecoder
-        }
-
-        // Initialize TextEncoder/TextDecoder instances
-        this.textEncoder = new TextEncoder()
-        this.textDecoder = new TextDecoder()
-      }
-
-      // Define isFloat32Array directly on the instance
-      isFloat32Array(arr) {
-        return !!(
-          arr instanceof Float32Array ||
-          (arr &&
-            Object.prototype.toString.call(arr) === '[object Float32Array]')
-        )
-      }
-
-      // Define isTypedArray directly on the instance
-      isTypedArray(arr) {
-        return !!(ArrayBuffer.isView(arr) && !(arr instanceof DataView))
-      }
-    }
-
-    // Assign the PlatformNode class to the global object
-    global.PlatformNode = PlatformNode
-
-    // Also create an instance and assign it to global.platformNode (lowercase p)
-    global.platformNode = new PlatformNode()
-
-    // Ensure global.util exists and has the necessary methods
-    // This is needed because TensorFlow.js might look for these methods in global.util
-    if (!global.util) {
-      global.util = {}
-    }
-
-    // Add isFloat32Array method if it doesn't exist
-    if (!global.util.isFloat32Array) {
-      global.util.isFloat32Array = (arr) => {
-        return !!(
-          arr instanceof Float32Array ||
-          (arr &&
-            Object.prototype.toString.call(arr) === '[object Float32Array]')
-        )
-      }
-    }
-
-    // Add isTypedArray method if it doesn't exist
-    if (!global.util.isTypedArray) {
-      global.util.isTypedArray = (arr) => {
-        return !!(ArrayBuffer.isView(arr) && !(arr instanceof DataView))
-      }
-    }
-  } catch (error) {
-    console.warn('Failed to define global PlatformNode class:', error)
-  }
-}
-
-// Now load and run the actual CLI
-import('./dist/cli.js').catch((err) => {
-  console.error('Error loading CLI:', err)
-  process.exit(1)
-})

cli-package/cli-wrapper.js

@@ -1,113 +0,0 @@
-#!/usr/bin/env node
-
-/**
- * CLI Wrapper Script for @soulcraft/brainy-cli
- *
- * This script serves as a wrapper for the Brainy CLI, ensuring that command-line arguments
- * are properly passed to the CLI when invoked through the globally installed package.
- */
-
-// CRITICAL: Apply TensorFlow.js environment patch before importing any other modules
-// This prevents the "TextEncoder is not a constructor" error in Node.js environments
-// by ensuring the global.PlatformNode class is defined before TensorFlow.js loads
-function applyTensorFlowPatch() {
-  try {
-    // Define a custom Platform class that works in Node.js environments
-    class Platform {
-      constructor() {
-        // Create a util object with necessary methods and constructors
-        this.util = {
-          // Use native TextEncoder and TextDecoder constructors
-          TextEncoder: global.TextEncoder || TextEncoder,
-          TextDecoder: global.TextDecoder || TextDecoder
-        }
-
-        // Initialize using native constructors directly
-        this.textEncoder = new TextEncoder()
-        this.textDecoder = new TextDecoder()
-      }
-
-      // Define isTypedArray directly on the instance
-      isTypedArray(arr) {
-        return !!(ArrayBuffer.isView(arr) && !(arr instanceof DataView))
-      }
-    }
-
-    // Assign the Platform class to the global object as PlatformNode
-    global.PlatformNode = Platform
-    // Also create an instance and assign it to global.platformNode (lowercase p)
-    global.platformNode = new Platform()
-
-    console.log('Applied TensorFlow.js platform patch in CLI wrapper')
-  } catch (error) {
-    console.warn('Failed to apply TensorFlow.js platform patch:', error)
-  }
-}
-
-// Apply the patch immediately
-applyTensorFlowPatch()
-
-import { spawn } from 'child_process'
-import { fileURLToPath } from 'url'
-import { dirname, join } from 'path'
-import fs from 'fs'
-
-// Node.js v24+ compatibility patches are now applied above,
-// before any imports, to ensure TensorFlow.js can correctly
-// detect and use the TextEncoder/TextDecoder in the environment.
-
-// Get the directory of the current module
-const __filename = fileURLToPath(import.meta.url)
-const __dirname = dirname(__filename)
-
-// Find the main package
-const mainPackagePath = join(__dirname, 'node_modules', '@soulcraft', 'brainy')
-
-// Path to the actual CLI script in this package
-const cliPath = join(__dirname, 'dist', 'cli.js')
-
-// Check if the CLI script exists
-if (!fs.existsSync(cliPath)) {
-  console.error(`Error: CLI script not found at ${cliPath}`)
-  console.error(
-    'This is likely because the CLI was not built during package installation.'
-  )
-  console.error('Please reinstall the package with:')
-  console.error('npm uninstall -g @soulcraft/brainy-cli')
-  console.error('npm install -g @soulcraft/brainy-cli')
-  process.exit(1)
-}
-
-// Special handling for version flags
-if (process.argv.includes('--version') || process.argv.includes('-V')) {
-  // Read version directly from package.json to ensure it's always correct
-  try {
-    const packageJsonPath = join(__dirname, 'package.json')
-    const packageJson = JSON.parse(fs.readFileSync(packageJsonPath, 'utf8'))
-    console.log(packageJson.version)
-    process.exit(0)
-  } catch (error) {
-    console.error('Error loading version information:', error.message)
-    process.exit(1)
-  }
-}
-
-// Forward all arguments to the CLI script
-const args = process.argv.slice(2)
-
-// Check if npm is passing --force flag
-// When npm runs with --force, it sets the npm_config_force environment variable
-if (
-  process.env.npm_config_force === 'true' &&
-  args.includes('clear') &&
-  !args.includes('--force') &&
-  !args.includes('-f')
-) {
-  args.push('--force')
-}
-
-const cli = spawn('node', [cliPath, ...args], { stdio: 'inherit' })
-
-cli.on('close', (code) => {
-  process.exit(code)
-})

cli-package/package.json

@@ -1,67 +0,0 @@
-{
-  "name": "@soulcraft/brainy-cli",
-  "version": "0.19.0",
-  "description": "Command-line interface for the Brainy vector graph database",
-  "type": "module",
-  "bin": {
-    "brainy": "cli-wrapper.js"
-  },
-  "files": [
-    "cli-wrapper.js",
-    "README.md",
-    "dist/cli.js",
-    "dist/cli.js.map"
-  ],
-  "scripts": {
-    "build": "rollup -c rollup.config.js",
-    "prepare": "npm run build",
-    "postinstall": "node cli-wrapper.js --version",
-    "version": "echo 'Version updated in package.json'",
-    "version:patch": "npm version patch",
-    "version:minor": "npm version minor",
-    "version:major": "npm version major",
-    "deploy": "npm run build && npm publish",
-    "dry-run": "npm pack --dry-run"
-  },
-  "keywords": [
-    "vector-database",
-    "hnsw",
-    "cli",
-    "browser",
-    "container",
-    "graph-database"
-  ],
-  "author": "David Snelling (david@soulcraft.com)",
-  "license": "MIT",
-  "private": false,
-  "publishConfig": {
-    "access": "public"
-  },
-  "homepage": "https://github.com/soulcraft-research/brainy",
-  "bugs": {
-    "url": "https://github.com/soulcraft-research/brainy/issues"
-  },
-  "repository": {
-    "type": "git",
-    "url": "git+https://github.com/soulcraft-research/brainy.git"
-  },
-  "dependencies": {
-    "@soulcraft/brainy": "^0.24.0",
-    "commander": "^14.0.0",
-    "omelette": "^0.4.17"
-  },
-  "devDependencies": {
-    "@rollup/plugin-commonjs": "^25.0.7",
-    "@rollup/plugin-json": "^6.1.0",
-    "@rollup/plugin-node-resolve": "^15.2.3",
-    "@rollup/plugin-typescript": "^11.1.6",
-    "@types/node": "^20.11.30",
-    "@types/omelette": "^0.4.5",
-    "rollup": "^4.13.0",
-    "rollup-plugin-terser": "^7.0.2",
-    "typescript": "^5.4.5"
-  },
-  "engines": {
-    "node": ">=24.4.0"
-  }
-}

cli-package/rollup.config.js

@@ -1,44 +0,0 @@
-import typescript from '@rollup/plugin-typescript'
-import resolve from '@rollup/plugin-node-resolve'
-import commonjs from '@rollup/plugin-commonjs'
-import json from '@rollup/plugin-json'
-import { terser } from 'rollup-plugin-terser'
-
-// CLI configuration
-export default {
-  input: 'src/cli.ts',
-  context: 'this', // Preserve 'this' context to fix TensorFlow.js issue
-  output: {
-    dir: 'dist',
-    entryFileNames: 'cli.js',
-    format: 'es',
-    sourcemap: true,
-    inlineDynamicImports: true
-  },
-  plugins: [
-    resolve({
-      browser: false,
-      preferBuiltins: true
-    }),
-    commonjs({
-      transformMixedEsModules: true
-    }),
-    json(),
-    typescript({
-      tsconfig: './tsconfig.json',
-      declaration: false,
-      declarationMap: false
-    })
-  ],
-  external: [
-    // External dependencies that should not be bundled
-    '@soulcraft/brainy',
-    'commander',
-    'omelette',
-    'fs',
-    'path',
-    'url',
-    'child_process',
-    'worker_threads'
-  ]
-}

cli-package/src/setup.ts

@@ -1,12 +0,0 @@
-/**
- * This file is imported for its side effects to patch the environment
- * for TensorFlow.js before any other library code runs.
- *
- * It ensures that by the time TensorFlow.js is imported by any other
- * module, the necessary compatibility fixes for the current Node.js
- * environment are already in place.
- */
-import { applyTensorFlowPatch } from './utils/textEncoding.js'
-
-// Apply the TensorFlow.js platform patch if needed
-applyTensorFlowPatch()

cli-package/src/utils/textEncoding.ts

@@ -1,98 +0,0 @@
-/**
- * Unified Text Encoding Utilities
- *
- * This module provides a consistent way to handle text encoding/decoding across all environments
- * using the native TextEncoder/TextDecoder APIs.
- */
-
-/**
- * Get a text encoder that works in the current environment
- * @returns A TextEncoder instance
- */
-export function getTextEncoder(): TextEncoder {
-  return new TextEncoder()
-}
-
-/**
- * Get a text decoder that works in the current environment
- * @returns A TextDecoder instance
- */
-export function getTextDecoder(): TextDecoder {
-  return new TextDecoder()
-}
-
-/**
- * Apply the TensorFlow.js platform patch if needed
- * This function patches the global object to provide a PlatformNode class
- * that uses native TextEncoder/TextDecoder
- */
-export function applyTensorFlowPatch(): void {
-  try {
-    // Define a custom Platform class that works in both Node.js and browser environments
-    class Platform {
-      util: any
-      textEncoder: TextEncoder
-      textDecoder: TextDecoder
-
-      constructor() {
-        // Create a util object with necessary methods and constructors
-        // Store the actual constructor functions, not just references
-        const TextEncoderConstructor = globalThis.TextEncoder || TextEncoder
-        const TextDecoderConstructor = globalThis.TextDecoder || TextDecoder
-
-        this.util = {
-          // Use native TextEncoder and TextDecoder constructors
-          TextEncoder: TextEncoderConstructor,
-          TextDecoder: TextDecoderConstructor
-        }
-
-        // Initialize using native constructors directly
-        this.textEncoder = new TextEncoderConstructor()
-        this.textDecoder = new TextDecoderConstructor()
-      }
-
-      // Define isFloat32Array directly on the instance
-      isFloat32Array(arr: any) {
-        return !!(
-          arr instanceof Float32Array ||
-          (arr &&
-            Object.prototype.toString.call(arr) === '[object Float32Array]')
-        )
-      }
-
-      // Define isTypedArray directly on the instance
-      isTypedArray(arr: any) {
-        return !!(ArrayBuffer.isView(arr) && !(arr instanceof DataView))
-      }
-    }
-
-    // Get the global object in a way that works in both Node.js and browser
-    const globalObj =
-      typeof global !== 'undefined'
-        ? global
-        : typeof window !== 'undefined'
-          ? window
-          : typeof self !== 'undefined'
-            ? self
-            : {}
-
-    // Only apply in Node.js environment
-    if (
-      typeof process !== 'undefined' &&
-      process.versions &&
-      process.versions.node
-    ) {
-      // Assign the Platform class to the global object as PlatformNode for Node.js
-      ;(globalObj as any).PlatformNode = Platform
-      // Also create an instance and assign it to global.platformNode (lowercase p)
-      ;(globalObj as any).platformNode = new Platform()
-    } else if (typeof window !== 'undefined' || typeof self !== 'undefined') {
-      // In browser environments, we might need to provide similar functionality
-      // but we'll use a different name to avoid conflicts
-      ;(globalObj as any).PlatformBrowser = Platform
-      ;(globalObj as any).platformBrowser = new Platform()
-    }
-  } catch (error) {
-    console.warn('Failed to apply TensorFlow.js platform patch:', error)
-  }
-}

cli-package/tsconfig.json

@@ -1,19 +0,0 @@
-{
-  "compilerOptions": {
-    "target": "ES2020",
-    "module": "ESNext",
-    "moduleResolution": "node",
-    "esModuleInterop": true,
-    "strict": true,
-    "noImplicitAny": false,
-    "outDir": "dist",
-    "declaration": true,
-    "sourceMap": true,
-    "skipLibCheck": true,
-    "paths": {
-      "@soulcraft/brainy": ["../dist/unified.d.ts"]
-    }
-  },
-  "include": ["src/**/*", "types.d.ts"],
-  "exclude": ["node_modules", "dist"]
-}

cli-package/types.d.ts

@@ -1,90 +0,0 @@
-// Type declarations for @soulcraft/brainy
-declare module '@soulcraft/brainy' {
-  // Core types
-  export class BrainyData {
-    constructor(config?: any)
-
-    init(): Promise<void>
-
-    add(text: string, metadata?: any): Promise<string>
-
-    get(id: string): Promise<any>
-
-    delete(id: string): Promise<void>
-
-    search(query: string, limit?: number, options?: any): Promise<any[]>
-
-    searchText(query: string, limit?: number, options?: any): Promise<any[]>
-
-    addVerb(
-      sourceId: string,
-      targetId: string,
-      text?: string,
-      options?: any
-    ): Promise<string>
-
-    getVerbsBySource(sourceId: string): Promise<any[]>
-
-    getVerbsByTarget(targetId: string): Promise<any[]>
-
-    status(): Promise<any>
-
-    clear(): Promise<void>
-
-    backup(): Promise<any>
-
-    restore(data: any, options?: any): Promise<any>
-
-    importSparseData(data: any, options?: any): Promise<any>
-
-    generateRandomGraph(options?: any): Promise<any>
-  }
-
-  export class FileSystemStorage {
-    constructor(dataDir: string)
-  }
-
-  // Pipelines
-  export const sequentialPipeline: any
-  export const augmentationPipeline: any
-
-  // Enums
-  export enum NounType {
-    Person = 'Person',
-    Place = 'Place',
-    Thing = 'Thing',
-    Event = 'Event',
-    Concept = 'Concept',
-    Content = 'Content'
-  }
-
-  export enum VerbType {
-    RelatedTo = 'RelatedTo',
-    PartOf = 'PartOf',
-    HasA = 'HasA',
-    UsedFor = 'UsedFor',
-    CapableOf = 'CapableOf',
-    AtLocation = 'AtLocation',
-    Causes = 'Causes',
-    HasProperty = 'HasProperty',
-    Owns = 'Owns',
-    CreatedBy = 'CreatedBy'
-  }
-
-  export enum ExecutionMode {
-    SEQUENTIAL = 'sequential',
-    PARALLEL = 'parallel',
-    THREADED = 'threaded'
-  }
-
-  export enum AugmentationType {
-    SENSE = 'sense',
-    MEMORY = 'memory',
-    COGNITION = 'cognition',
-    CONDUIT = 'conduit',
-    ACTIVATION = 'activation',
-    PERCEPTION = 'perception',
-    DIALOG = 'dialog',
-    WEBSOCKET = 'websocket'
-  }
-}

cli-wrapper.js

@@ -1,85 +0,0 @@
-#!/usr/bin/env node
-
-/**
- * CLI Wrapper Script
- *
- * This script serves as a wrapper for the Brainy CLI, ensuring that command-line arguments
- * are properly passed to the CLI when invoked through npm scripts.
- */
-
-import { spawn, execSync } from 'child_process'
-import { fileURLToPath } from 'url'
-import { dirname, join } from 'path'
-import fs from 'fs'
-
-
-// Get the directory of the current module
-const __filename = fileURLToPath(import.meta.url)
-const __dirname = dirname(__filename)
-
-// Path to the actual CLI script
-const cliPath = join(__dirname, 'dist', 'cli.js')
-
-// Check if the CLI script exists
-if (!fs.existsSync(cliPath)) {
-  // Check if we're running in a global installation context
-  const isGlobalInstall = __dirname.includes('node_modules') && !__dirname.includes('node_modules/.')
-
-  if (isGlobalInstall) {
-    console.error(`Error: CLI script not found at ${cliPath}`)
-    console.error('This is likely because the CLI was not built during package installation.')
-    console.error('Please reinstall the package with:')
-    console.error('npm uninstall -g @soulcraft/brainy')
-    console.error('npm install -g @soulcraft/brainy --legacy-peer-deps')
-    process.exit(1)
-  } else {
-    // In a local development context, try to build the CLI
-    console.log(`CLI script not found at ${cliPath}. Building CLI...`)
-
-    try {
-      // Run the build:cli script
-      execSync('npm run build:cli', { stdio: 'inherit' })
-
-      // Check again if the CLI script exists after building
-      if (!fs.existsSync(cliPath)) {
-        console.error(`Error: Failed to build CLI script at ${cliPath}`)
-        process.exit(1)
-      }
-
-      console.log('CLI built successfully.')
-    } catch (error) {
-      console.error(`Error building CLI: ${error.message}`)
-      console.error('Make sure you have the necessary dependencies installed.')
-      process.exit(1)
-    }
-  }
-}
-
-// Special handling for version flags
-if (process.argv.includes('--version') || process.argv.includes('-V')) {
-  // Read version directly from package.json to ensure it's always correct
-  try {
-    const packageJsonPath = join(__dirname, 'package.json')
-    const packageJson = JSON.parse(fs.readFileSync(packageJsonPath, 'utf8'))
-    console.log(packageJson.version)
-    process.exit(0)
-  } catch (error) {
-    console.error('Error loading version information:', error.message)
-    process.exit(1)
-  }
-}
-
-// Forward all arguments to the CLI script
-const args = process.argv.slice(2)
-
-// Check if npm is passing --force flag
-// When npm runs with --force, it sets the npm_config_force environment variable
-if (process.env.npm_config_force === 'true' && args.includes('clear') && !args.includes('--force') && !args.includes('-f')) {
-  args.push('--force')
-}
-
-const cli = spawn('node', [cliPath, ...args], { stdio: 'inherit' })
-
-cli.on('close', (code) => {
-  process.exit(code)
-})

demo.md

@@ -1,65 +0,0 @@
-# Running the Brainy Demo
-
-The Brainy interactive demo showcases the library's features in a web browser. Follow these steps to run it:
-
-## Prerequisites
-
-- Make sure you have Node.js installed (version 24.4.0 or higher)
-- Ensure the project is built (run both `npm run build` and `npm run build:browser`)
-
-## Running the Demo
-
-### Option 1: Using the npm script (recommended)
-
-Run the following command from the project root:
-
-```bash
-npm run demo
-```
-
-This will start an HTTP server and automatically open the demo in your default browser.
-
-### Option 2: Manual setup
-
-1. Start an HTTP server in the project root:
-
-```bash
-npx http-server
-```
-
-2. Open your browser and navigate to:
-   http://localhost:8080/demo/index.html
-
-## Troubleshooting
-
-If you see the error "Could not load Brainy library. Please ensure the project is built and served over HTTP", check the
-following:
-
-1. Make sure you've built the project with `npm run build && npm run build:browser`
-2. Ensure you're accessing the demo through HTTP (not by opening the file directly)
-3. Check your browser's console for additional error messages
-
-If issues persist, try clearing your browser cache or using a private/incognito window.
-
-## Build Process
-
-The Brainy library uses a two-step build process:
-
-1. `npm run build` - Compiles TypeScript files to JavaScript (used for Node.js environments)
-2. `npm run build:browser` - Creates a browser-compatible bundle using Rollup
-
-You can run both steps together with:
-
-```bash
-npm run build && npm run build:browser
-```
-
-Or simply use the demo script which does this for you:
-
-```bash
-npm run demo
-```
-
-The browser bundle is created from `src/unified.ts`, which provides environment detection and adapts to browser,
-Node.js, or serverless environments. This unified approach ensures that the library works correctly across all
-environments.

demo/CNAME

@@ -1 +0,0 @@
-demo.soulcraft.com

demo/test-browser-worker.html

@@ -1,104 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-<head>
-  <meta charset="UTF-8">
-  <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  <title>Brainy Browser Worker Test</title>
-  <style>
-    body {
-      font-family: Arial, sans-serif;
-      max-width: 800px;
-      margin: 0 auto;
-      padding: 20px;
-    }
-    .result {
-      margin-top: 20px;
-      padding: 10px;
-      border: 1px solid #ccc;
-      border-radius: 5px;
-      background-color: #f9f9f9;
-    }
-    button {
-      padding: 10px 15px;
-      background-color: #4CAF50;
-      color: white;
-      border: none;
-      border-radius: 4px;
-      cursor: pointer;
-    }
-    button:hover {
-      background-color: #45a049;
-    }
-    pre {
-      white-space: pre-wrap;
-      word-wrap: break-word;
-    }
-  </style>
-</head>
-<body>
-  <h1>Brainy Browser Worker Test</h1>
-  <p>This page tests the Brainy worker thread implementation in a browser environment.</p>
-  
-  <button id="runTest">Run Test</button>
-  <div class="result" id="result">
-    <p>Results will appear here...</p>
-  </div>
-
-  <script type="module">
-    import { executeInThread, environment, isThreadingAvailable } from '../dist/unified.js';
-
-    document.getElementById('runTest').addEventListener('click', async () => {
-      const resultDiv = document.getElementById('result');
-      resultDiv.innerHTML = '<p>Running test...</p>';
-
-      try {
-        // Log environment information
-        resultDiv.innerHTML += `<p>Environment: ${JSON.stringify(environment)}</p>`;
-        
-        // Check if threading is available
-        const threadingAvailable = typeof isThreadingAvailable === 'function' 
-          ? isThreadingAvailable() 
-          : 'isThreadingAvailable function not found';
-        resultDiv.innerHTML += `<p>Threading available: ${threadingAvailable}</p>`;
-
-        // Define a compute-intensive function
-        const computeIntensiveFunction = `
-          function(data) {
-            console.log('Worker: Starting computation...');
-
-            // Simulate a compute-intensive task
-            const start = Date.now();
-            let result = 0;
-            for (let i = 0; i < data.iterations; i++) {
-              result += Math.sqrt(i) * Math.sin(i);
-            }
-
-            const duration = Date.now() - start;
-            console.log('Worker: Computation completed in ' + duration + 'ms');
-
-            return {
-              result,
-              duration,
-              iterations: data.iterations
-            };
-          }
-        `;
-
-        // Execute the function in a worker thread
-        resultDiv.innerHTML += '<p>Starting worker thread execution...</p>';
-        const startTime = Date.now();
-        
-        const result = await executeInThread(computeIntensiveFunction, { iterations: 5000000 });
-        
-        const mainDuration = Date.now() - startTime;
-        resultDiv.innerHTML += `<p>Worker thread execution completed in ${mainDuration}ms</p>`;
-        resultDiv.innerHTML += `<pre>${JSON.stringify(result, null, 2)}</pre>`;
-        
-      } catch (error) {
-        resultDiv.innerHTML += `<p>Error: ${error.message}</p>`;
-        console.error('Error during test:', error);
-      }
-    });
-  </script>
-</body>
-</html>

demo/test-fallback.html

@@ -1,142 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-<head>
-  <meta charset="UTF-8">
-  <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  <title>Brainy Fallback Test</title>
-  <style>
-      body {
-          font-family: Arial, sans-serif;
-          max-width: 800px;
-          margin: 0 auto;
-          padding: 20px;
-      }
-
-      .result {
-          margin-top: 20px;
-          padding: 10px;
-          border: 1px solid #ccc;
-          border-radius: 5px;
-          background-color: #f9f9f9;
-      }
-
-      button {
-          padding: 10px 15px;
-          background-color: #4CAF50;
-          color: white;
-          border: none;
-          border-radius: 4px;
-          cursor: pointer;
-      }
-
-      button:hover {
-          background-color: #45a049;
-      }
-
-      pre {
-          white-space: pre-wrap;
-          word-wrap: break-word;
-      }
-  </style>
-</head>
-<body>
-<h1>Brainy Fallback Test</h1>
-<p>This page tests the Brainy fallback mechanism when threading is not available.</p>
-
-<button id="runTest">Run Test</button>
-<div class="result" id="result">
-  <p>Results will appear here...</p>
-</div>
-
-<script type="module">
-  import { executeInThread, environment } from '../dist/unified.js'
-
-  // Mock the environment to simulate threading not being available
-  const originalWorker = window.Worker
-
-  document.getElementById('runTest').addEventListener('click', async () => {
-    const resultDiv = document.getElementById('result')
-    resultDiv.innerHTML = '<p>Running test...</p>'
-
-    try {
-      // Log environment information
-      resultDiv.innerHTML += `<p>Original Environment: ${JSON.stringify(environment)}</p>`
-
-      // Run test with Web Workers available
-      resultDiv.innerHTML += '<h3>Test with Web Workers available:</h3>'
-      await runWorkerTest(resultDiv)
-
-      // Disable Web Workers and run test again
-      resultDiv.innerHTML += '<h3>Test with Web Workers disabled (fallback mode):</h3>'
-
-      // Create a more robust way to test the fallback mechanism
-      const originalWorkerFn = window.Worker;
-      window.Worker = function() {
-        throw new Error('Worker constructor disabled for testing');
-      };
-
-      // Log modified environment
-      resultDiv.innerHTML += `<p>Modified Environment (Worker disabled): ${typeof window.Worker}</p>`
-
-      try {
-        await runWorkerTest(resultDiv);
-      } finally {
-        // Ensure Worker is restored
-        window.Worker = originalWorkerFn;
-        resultDiv.innerHTML += '<p>Test completed. Web Workers restored.</p>';
-      }
-
-    } catch (error) {
-      resultDiv.innerHTML += `<p>Error: ${error.message}</p>`
-      console.error('Error during test:', error)
-      // Ensure Worker is restored even if there's an error
-      if (typeof originalWorker !== 'undefined') {
-        window.Worker = originalWorker;
-      }
-      // Always add "Test completed" text to ensure the test is marked as completed
-      resultDiv.innerHTML += '<p>Test completed with errors.</p>';
-    }
-  })
-
-  async function runWorkerTest(resultDiv) {
-    // Define a compute-intensive function using a simple anonymous function expression
-    // This format works with both worker and fallback mechanisms
-    const computeIntensiveFunction = `function(data) {
-            console.log('Worker/Fallback: Starting computation...');
-
-            // Simulate a compute-intensive task
-            const start = Date.now();
-            let result = 0;
-            for (let i = 0; i < data.iterations; i++) {
-              result += Math.sqrt(i) * Math.sin(i);
-            }
-
-            const duration = Date.now() - start;
-            console.log('Worker/Fallback: Computation completed in ' + duration + 'ms');
-
-            const globalObj = typeof self !== 'undefined' ? self : 
-                             typeof window !== 'undefined' ? window : 
-                             {};
-
-            return {
-              result,
-              duration,
-              iterations: data.iterations,
-              webWorkersAvailable: typeof globalObj.Worker !== 'undefined'
-            };
-          }
-      `
-
-    // Execute the function
-    resultDiv.innerHTML += '<p>Starting execution...</p>'
-    const startTime = Date.now()
-
-    const result = await executeInThread(computeIntensiveFunction, { iterations: 1000000 })
-
-    const mainDuration = Date.now() - startTime
-    resultDiv.innerHTML += `<p>Execution completed in ${mainDuration}ms</p>`
-    resultDiv.innerHTML += `<pre>${JSON.stringify(result, null, 2)}</pre>`
-  }
-</script>
-</body>
-</html>

demo/test-tensorflow-textencoder.html

@@ -1,159 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-<head>
-  <meta charset="UTF-8">
-  <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  <title>Brainy TensorFlow and TextEncoder Test</title>
-  <style>
-      body {
-          font-family: Arial, sans-serif;
-          max-width: 800px;
-          margin: 0 auto;
-          padding: 20px;
-      }
-
-      .result {
-          margin-top: 20px;
-          padding: 10px;
-          border: 1px solid #ccc;
-          border-radius: 5px;
-          background-color: #f9f9f9;
-      }
-
-      button {
-          padding: 10px 15px;
-          background-color: #4CAF50;
-          color: white;
-          border: none;
-          border-radius: 4px;
-          cursor: pointer;
-      }
-
-      button:hover {
-          background-color: #45a049;
-      }
-
-      pre {
-          white-space: pre-wrap;
-          word-wrap: break-word;
-      }
-
-      .success {
-          color: green;
-          font-weight: bold;
-      }
-
-      .error {
-          color: red;
-          font-weight: bold;
-      }
-  </style>
-</head>
-<body>
-<h1>Brainy TensorFlow and TextEncoder Test</h1>
-<p>This page tests TensorFlow.js and TextEncoder functionality in a browser environment.</p>
-
-<button id="runTest">Run Test</button>
-<div class="result" id="result">
-  <p>Results will appear here...</p>
-</div>
-
-<script type="module">
-  // Implement the necessary functions directly
-  function applyTensorFlowPatch() {
-    console.log('Applying TensorFlow patch directly in test file')
-    return true
-  }
-
-  function getTextEncoder() {
-    return new TextEncoder()
-  }
-
-  function getTextDecoder() {
-    return new TextDecoder()
-  }
-
-  // We need to dynamically import TensorFlow.js
-  async function loadTensorFlow() {
-    // Import TensorFlow.js dynamically
-    const tf = await import('https://cdn.jsdelivr.net/npm/@tensorflow/tfjs@4.22.0/dist/tf.min.js')
-    return tf
-  }
-
-  document.getElementById('runTest').addEventListener('click', async () => {
-    const resultDiv = document.getElementById('result')
-    resultDiv.innerHTML = '<p>Running test...</p>'
-
-    try {
-      // Apply TensorFlow patch for TextEncoder compatibility
-      applyTensorFlowPatch()
-      resultDiv.innerHTML += '<p>TensorFlow patch applied successfully</p>'
-
-      // Test TextEncoder
-      resultDiv.innerHTML += '<h3>Testing TextEncoder</h3>'
-      const encoder = getTextEncoder()
-      const decoder = getTextDecoder()
-
-      const testString = 'Hello, world! 👋'
-      resultDiv.innerHTML += `<p>Original string: "${testString}"</p>`
-
-      const encoded = encoder.encode(testString)
-      resultDiv.innerHTML += `<p>Encoded: [${Array.from(encoded).join(', ')}]</p>`
-
-      const decoded = decoder.decode(encoded)
-      resultDiv.innerHTML += `<p>Decoded: "${decoded}"</p>`
-
-      if (testString === decoded) {
-        resultDiv.innerHTML += '<p class="success">✅ TextEncoder/TextDecoder test passed!</p>'
-      } else {
-        resultDiv.innerHTML += '<p class="error">❌ TextEncoder/TextDecoder test failed!</p>'
-        throw new Error('TextEncoder/TextDecoder test failed')
-      }
-
-      // Test TensorFlow.js
-      resultDiv.innerHTML += '<h3>Testing TensorFlow.js</h3>'
-      resultDiv.innerHTML += '<p>Loading TensorFlow.js...</p>'
-
-      const tf = await loadTensorFlow()
-      resultDiv.innerHTML += '<p>TensorFlow.js loaded successfully</p>'
-
-      // Create a simple tensor
-      const tensor = tf.tensor2d([[1, 2], [3, 4]])
-      resultDiv.innerHTML += '<p>Created tensor: [[1, 2], [3, 4]]</p>'
-
-      // Perform a simple operation
-      const result = tensor.add(tf.scalar(1))
-      resultDiv.innerHTML += '<p>Result of adding 1 to tensor</p>'
-
-      // Check the values
-      const values = await result.array()
-      const expected = [[2, 3], [4, 5]]
-
-      resultDiv.innerHTML += `<p>Result values: ${JSON.stringify(values)}</p>`
-      resultDiv.innerHTML += `<p>Expected values: ${JSON.stringify(expected)}</p>`
-
-      // Compare values
-      const match = JSON.stringify(values) === JSON.stringify(expected)
-      if (match) {
-        resultDiv.innerHTML += '<p class="success">✅ TensorFlow.js test passed!</p>'
-      } else {
-        resultDiv.innerHTML += '<p class="error">❌ TensorFlow.js test failed!</p>'
-        throw new Error('TensorFlow.js test failed')
-      }
-
-      resultDiv.innerHTML += '<h3 class="success">All tests passed successfully!</h3>'
-
-      // Add a marker that Puppeteer can detect to know the test is complete
-      resultDiv.innerHTML += '<p id="testComplete">Test completed</p>'
-
-    } catch (error) {
-      resultDiv.innerHTML += `<p class="error">Error during test: ${error.message}</p>`
-      console.error('Error during test:', error)
-
-      // Add a marker that Puppeteer can detect to know the test is complete (even with error)
-      resultDiv.innerHTML += '<p id="testComplete">Test completed with errors</p>'
-    }
-  })
-</script>
-</body>
-</html>

docker-compose.yml

@@ -0,0 +1,62 @@
+version: '3.8'
+
+services:
+  brainy:
+    build: .
+    container_name: brainy-app
+    ports:
+      - "3000:3000"
+    environment:
+      - NODE_ENV=production
+      - BRAINY_STORAGE_TYPE=filesystem
+      - BRAINY_STORAGE_PATH=/app/data
+      - BRAINY_LOG_LEVEL=info
+      - BRAINY_RATE_LIMIT_MAX=100
+      - BRAINY_RATE_LIMIT_WINDOW_MS=900000
+    volumes:
+      # Persistent storage for data
+      - brainy-data:/app/data
+      # Optional: Mount local models directory
+      # - ./models:/app/models:ro
+    healthcheck:
+      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
+      interval: 30s
+      timeout: 3s
+      retries: 3
+      start_period: 10s
+    restart: unless-stopped
+    networks:
+      - brainy-network
+
+  # Optional: MinIO for S3-compatible storage (development)
+  minio:
+    image: minio/minio:latest
+    container_name: brainy-minio
+    ports:
+      - "9000:9000"
+      - "9001:9001"
+    environment:
+      - MINIO_ROOT_USER=brainy
+      - MINIO_ROOT_PASSWORD=brainy123456
+    volumes:
+      - minio-data:/data
+    command: server /data --console-address ":9001"
+    healthcheck:
+      test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]
+      interval: 30s
+      timeout: 20s
+      retries: 3
+    networks:
+      - brainy-network
+    profiles:
+      - with-s3
+
+volumes:
+  brainy-data:
+    driver: local
+  minio-data:
+    driver: local
+
+networks:
+  brainy-network:
+    driver: bridge

docs/ADR-001-generational-mvcc.md

@@ -0,0 +1,295 @@
+# ADR-001: Generational MVCC storage and the immutable Db API
+
+**Status:** Accepted (ships in 8.0)
+**Date:** 2026-06-10
+
+## Context
+
+Before 8.0, Brainy carried two overlapping version-control subsystems: a
+copy-on-write branching layer (`fork`/`checkout`/`commit`/`branches`) and a
+separate versioning subsystem (`versions.save/list/compare/restore/prune`),
+plus a read-only historical adapter for commit-based time travel. Together
+they were ~5,100 LOC of mechanism for one product need: *read a consistent
+past state while the store keeps moving, and snapshot/restore cheaply.*
+
+Neither subsystem gave a precise isolation guarantee. Reads raced in-place
+JSON overwrites, so a "snapshot" was only as immutable as the bytes it
+happened to share with the live store.
+
+8.0 replaces both with **one mechanism**: generational MVCC over immutable,
+generation-stamped records, exposed through a Datomic-style immutable
+database value (`Db`). The same model is implemented natively by versioned
+index providers (LSM snapshots), so semantics are identical on the pure-JS
+path and the native path.
+
+## Decision
+
+### The model
+
+- A **monotonic u64 generation counter** is the store's logical clock. It
+  advances once per committed `transact()` batch and once per
+  single-operation write (`add`/`update`/`remove`/`relate`/…), so
+  `brain.generation()` is always a meaningful watermark. It is persisted in
+  `_system/generation.json` and never reissued for anything durable.
+- `brain.now()` **pins** the current generation in O(1) and returns a `Db` —
+  an immutable view. Pins are refcounted; `db.release()` (with a
+  `FinalizationRegistry` backstop for leaked values) ends the pin.
+- `brain.transact(ops, { meta, ifAtGeneration })` commits a declarative
+  batch atomically as **exactly one generation**, with whole-store
+  compare-and-swap (`ifAtGeneration` → `GenerationConflictError`) and
+  reified transaction metadata appended to `_system/tx-log.jsonl`.
+- `brain.asOf(generation | Date | snapshotPath)` opens past state;
+  `db.with(ops)` layers a speculative in-memory overlay (never touching
+  disk, the counter, or index providers); `db.persist(path)` cuts an
+  instant snapshot; `brain.restore(path, { confirm: true })` replaces state
+  from one; `Brainy.load(path)` opens a snapshot read-only with the full
+  query surface.
+
+### Persisted layout
+
+All paths are storage-root-relative:
+
+```
+_system/generation.json          { generation, updatedAt }       atomic tmp+rename
+_system/manifest.json            { version, generation,          atomic tmp+rename
+                                   committedAt, horizon }        (the commit point)
+_system/tx-log.jsonl             one line per committed          append-only
+                                 transact: { generation,
+                                 timestamp, meta? }
+_generations/<N>/tx.json         the generation-N delta:         immutable
+                                 touched noun/verb ids + meta
+_generations/<N>/prev/<id>.json  before-image of <id> as of      immutable
+                                 commit N (raw stored bytes;
+                                 null parts = file was absent)
+```
+
+**Why per-generation deltas instead of a global `id → latest generation`
+map in the manifest:** a global map makes every commit O(all ids) — the
+whole map must be rewritten to swap it atomically. The delta layout makes a
+commit O(ids touched) and keeps the manifest a fixed-size watermark, while
+point-in-time resolution stays correct (see "Read resolution" below). The
+trade is that resolution at a pinned generation scans the deltas of later
+commits — bounded by the number of commits since the pin, which is exactly
+the window compaction keeps short.
+
+Before-images are deliberately the *only* per-id records. They serve both
+roles the layer needs — the crash-recovery undo log and the point-in-time
+read source. After-images would duplicate state that is already readable
+(the canonical entity files hold the latest bytes; earlier states resolve
+from later before-images) and would double record I/O per commit.
+
+### Commit protocol (durability)
+
+`transact()` commits under a store-wide mutex:
+
+1. **CAS check.** A stale `ifAtGeneration` throws `GenerationConflictError`
+   before anything is staged.
+2. **Reserve** generation `N` (counter increment).
+3. **Stage the undo log:** write the before-image of every touched id plus
+   `tx.json` under `_generations/N/`, then **fsync** the files and their
+   directories. From this point, any crash is recoverable to the exact
+   pre-transaction bytes.
+4. **Execute** the planned batch through the TransactionManager (which has
+   its own operation-level rollback for in-flight failures).
+5. **Commit point:** persist the counter, then write `_system/manifest.json`
+   via atomic tmp+rename and fsync it. The rename *is* the commit: a
+   generation directory is committed if and only if `N ≤
+   manifest.generation`.
+6. Append the tx-log line (advisory metadata — a crash between 5 and 6
+   keeps the transaction).
+
+**Crash recovery (on open):** any `_generations/<N>` directory with
+`N > manifest.generation` is an uncommitted transaction. Its before-images
+are restored to the canonical paths (idempotently — recovery itself can
+crash and rerun) and the directory is removed. Because recovery runs before
+any index is built, and a recovery that rolled something back forces a full
+index rebuild, derived indexes never observe rolled-back state. Reader-mode
+instances skip recovery (readers never write; the next writer repairs).
+
+A failed (non-crash) transaction takes the same staging directory down the
+abort path: the TransactionManager rolls back applied operations, the
+staging directory is removed, and the generation reservation is returned —
+a failed batch leaves the generation counter unchanged.
+
+### Read resolution at a pinned generation
+
+The state of id X at pinned generation G is:
+
+- the before-image stored by the **first committed generation after G that
+  touched X**, or
+- the live canonical bytes, when nothing after G touched X.
+
+While nothing has committed past G, *every* read on the `Db` delegates to
+the live fast paths untouched — `now()` adds no read overhead until history
+actually moves.
+
+**Two read paths, one result set.** `get()`, metadata-level `find()`, and
+filter-based `related()` resolve directly through the record layer at any
+reachable pinned generation — no extra cost beyond scanning the deltas of
+later commits. Index-accelerated dimensions (semantic/vector search, graph
+traversal, cursors, aggregation) are served by **at-generation index
+materialization**: the first such query on a historical `Db` copies the
+exact at-G record set (live bytes for ids untouched since the pin,
+before-images for the rest; a final reconciliation pass runs under the
+commit mutex so transactions racing the copy cannot skew it) into an
+ephemeral in-memory store and opens a read-only engine over it — the same
+vector/metadata/graph index classes the live brain uses, sharing the host's
+embedder and aggregate definitions. The handle is cached on the `Db` and
+freed by `release()`.
+
+**Cost, stated plainly:** materialization is O(n at G) time and memory,
+once per `Db`. That is the open-core price of historical index queries. A
+native `VersionedIndexProvider` (`isGenerationVisible()` + pins over
+retained LSM segments) serves the same reads with no rebuild at all — the
+materializer is the correctness baseline, the provider is the accelerator.
+
+**The one remaining boundary.** Speculative `with()` overlays throw
+`SpeculativeOverlayError` for index-accelerated queries and `persist()`:
+overlay entities carry no embeddings (`with()` never invokes the embedder),
+so a "full" index query over an overlay would silently exclude the
+overlay's own entities. Commit with `transact()` to get the full surface.
+
+**History granularity (Model-B).** EVERY write is its own immutable generation
+— `transact()` batches AND single-operation `add`/`update`/`remove`/`relate`.
+Single-ops stage a before-image and are reported by `db.since()`/`asOf()`/
+`diff()`/`history()` exactly like transacts; a pin always freezes against later
+writes. `transact()` groups several operations into ONE atomic generation.
+
+Single-op history durability is **async group-commit**: the live write hits
+canonical storage immediately (acknowledged), while its before-image is buffered
+and persisted to disk in one batched fsync on a size/timer trigger (or forced by
+`flush()`/`close()`/`transact()`/`compactHistory()`). The buffer participates in
+point-in-time resolution exactly like on-disk generations, so the synchronous
+`now()` freezes with no forced flush. A hard crash before the flush loses only
+the buffered *history* of the last window — never live data — and a crash
+*mid-flush* is recovered by **drop-without-restore** (the partial generation's
+before-images are discarded, never replayed, because the live write was already
+acknowledged; restoring them would silently revert it).
+
+### Pinning, retention, compaction
+
+- Each live `Db` holds one refcounted pin on its generation (plus a
+  `pin(generation)` on every registered `VersionedIndexProvider`, whose
+  explicit pin lifetime overrides any time-based snapshot retention the
+  provider has).
+- The constructor **`retention`** knob governs auto-compaction (on `flush()`/
+  `close()`): unset → ADAPTIVE (disk/RAM-pressure byte budget, zero-config;
+  driven by a coordinator's `budgetBytes` or a local `os.freemem` probe) ·
+  `'all'` → unbounded · `{ maxGenerations?, maxAge?, maxBytes? }` → explicit
+  CAPS. `compactHistory({ maxGenerations?, maxAge?, maxBytes? })` reclaims
+  manually on the same caps — the oldest unpinned record-sets are reclaimed
+  while ANY supplied cap is exceeded.
+- A record-set `N` is reclaimed only when `N` is at or below **every** live
+  pin — deleting `N` can only break readers pinned *below* `N`, because
+  resolution reads before-images from generations strictly greater than the
+  pin. Live pins are ALWAYS exempt, in every retention mode.
+- The manifest records the **horizon** (highest reclaimed generation).
+  Generations below the horizon are unreachable; `asOf()` on them throws
+  `GenerationCompactedError`. The horizon itself stays reachable, resolved
+  from the record-sets above it. To keep a generation readable forever,
+  `persist()` it first — snapshots are self-contained.
+
+### Snapshots and restore
+
+`db.persist(path)` flushes indexes, then cuts the snapshot under the
+store's commit mutex (no commit, compaction, or counter write can
+interleave). On filesystem storage it is a **hard-link farm**: every data
+file is immutable-by-rename, so linking is safe — later rewrites swap
+inodes and the snapshot keeps the old bytes. The two exceptions are handled
+explicitly: the append-in-place tx-log is byte-copied, and process-local
+lock state is excluded. Cross-device targets (and filesystems that refuse
+links) fall back to per-file byte copies. In-memory stores serialize to the
+same directory layout, so persisting a memory brain produces a real,
+durable, loadable store.
+
+`persist()` requires the view to still be the store's latest generation
+(a snapshot captures current bytes); a view that history has moved past
+throws rather than persisting the wrong state.
+
+`restore(path, { confirm: true })` replaces the store's contents from a
+snapshot via byte copy (never links — the snapshot stays independent),
+reloads all adapter-internal derived state, rebuilds all indexes, and
+floors the generation counter at its pre-restore value so observed
+generation numbers are never reissued. Live pins do not survive a restore;
+a warning is logged when any exist.
+
+### Versioned index providers
+
+Native index providers may implement the optional 4-method
+`VersionedIndexProvider` capability (`generation()`,
+`isGenerationVisible()`, `pin()`, `release()` — BigInt generations at the
+boundary). The locked consistency model: providers are **post-commit
+appliers**. The storage-record commit is the source of truth; provider
+index state is derived. On open, a provider behind the committed watermark
+replays the gap from storage (or requests a rebuild) — there are no
+provider rollback hooks, because uncommitted transactions are repaired at
+the storage layer before any index opens. Speculative `with()` overlays
+never reach providers.
+
+## Guarantees (and their proofs)
+
+Each stated guarantee has a test that proves it, not merely exercises it
+(`tests/integration/db-mvcc.test.ts`, plus
+`tests/unit/db/generationStore.test.ts` for the record layer in isolation):
+
+| Guarantee | Proof |
+|---|---|
+| Snapshot isolation: a pinned `Db` reads exactly its pinned state, forever | proof 1 (200 mutations, including deletes, against a pinned view) |
+| Atomicity: a failing batch applies nothing; generation unchanged | proofs 2a/2b/2c (plan-time failure, injected execution-phase storage failure, `ifRev` conflict) |
+| Whole-store CAS | proof 3 (`ifAtGeneration` success + conflict with exact expected/actual) |
+| Snapshot integrity under source mutation (hard-link safety) | proofs 4a/4b/4c |
+| Compaction never breaks a pinned read; release enables reclaim | proof 5 |
+| `with()` overlays touch nothing durable | proof 6 |
+| Generation monotonicity across close/reopen | proof 7 |
+| Crash before the manifest rename recovers to exact pre-transaction state through the real recovery path | proof 8 (fault injection that skips abort cleanup, exactly as a dead process would) |
+| Balanced provider pin/release lockstep | proof 9 |
+
+One deliberate softness: single-operation generation bumps persist the
+counter coalesced (per write burst), not per write. Durable artifacts —
+records, manifests, snapshots — always persist the counter synchronously at
+their own commit points, so a crash inside the coalescing window can lose
+only counter values that nothing durable ever referenced.
+
+## Failure modes
+
+| Failure | Outcome |
+|---|---|
+| Crash before staging completes | Partial staging directory > manifest watermark → removed on next open; canonical state untouched. |
+| Crash after staging, before/during batch execution | Before-images restored on next open; indexes rebuilt; byte-identical pre-transaction state. |
+| Crash after execution, before manifest rename | Same as above — the rename is the only commit point. |
+| Crash after manifest rename, before tx-log append | Transaction kept (committed); tx-log misses one advisory line; `asOf(Date)` resolution for that commit falls back to neighboring entries. |
+| Batch fails mid-execution (no crash) | TransactionManager operation rollback + staging-directory removal + reservation return; generation unchanged. |
+| `asOf()` below the compaction horizon | `GenerationCompactedError` — explicit, never partial data. |
+| Index-accelerated query on a `with()` overlay | `SpeculativeOverlayError` — explicit, never silently-incomplete results (overlay entities carry no embeddings). |
+| `persist()` of a view history has moved past | `GenerationConflictError` — a snapshot captures current bytes; persist before further writes. |
+| Torn trailing tx-log line (crashed append) | Tolerated; unparseable lines are skipped by readers. |
+
+## Lineage
+
+The design is an assembly of well-understood prior art, chosen for being
+boring where it counts:
+
+- **Datomic** — the database-as-a-value: an immutable `Db` you query, with
+  `with()` for speculation and reified transaction metadata instead of
+  commit messages.
+- **LMDB** — reader pins: readers never block writers; a reader's view
+  stays valid because nothing overwrites the pages (here: records) it
+  references; reclamation waits for the last reader.
+- **LSM trees / Cassandra** — immutable segments make snapshots hard links
+  and make compaction a retention policy instead of a locking problem.
+
+## Consequences
+
+- One mechanism replaces the COW and versioning subsystems (their removal
+  is the companion change to this ADR).
+- In-place branch switching (`checkout`) is gone by design; the replacement
+  is opening a persisted snapshot as a separate instance — a name→path
+  mapping where a product needs named branches.
+- Every commit pays O(ids touched) extra writes (before-images + delta +
+  manifest). Single-operation writes pay only an in-memory counter bump
+  with coalesced persistence.
+- The full query surface works at every reachable pinned generation.
+  Record-path reads (`get`, metadata `find`, filter `related`) are
+  effectively free; index-accelerated historical queries pay a one-time
+  O(n at G) materialization per `Db` on the open-core path (freed on
+  `release()`), and run rebuild-free on a native `VersionedIndexProvider`.

docs/BATCHING.md

@@ -0,0 +1,468 @@
+---
+title: Batch Operations
+slug: guides/batching
+public: true
+category: guides
+template: guide
+order: 5
+description: Eliminate N+1 query patterns with batchGet() and storage-level batch APIs for fast multi-entity reads against filesystem and memory storage.
+next:
+  - api/reference
+  - guides/find-system
+---
+
+# Batch Operations API
+> **Production-Ready** | Zero N+1 Query Patterns
+
+## Overview
+
+Brainy provides batch operations at the storage layer to eliminate N+1 query patterns for VFS operations, relationship queries, and entity retrieval.
+
+### Problem Solved
+
+The naive pattern of looping and calling `brain.get(id)` once per item issues sequential reads through the storage layer. Batched APIs collapse that into a single read pass.
+
+**IMPORTANT:** The batch optimizations apply **ONLY to `getTreeStructure()`** at the VFS layer and the explicit `batchGet()` / `getNounMetadataBatch()` calls — not to `readFile()` or individual `get()` operations.
+
+---
+
+## New Public APIs
+
+### 1. `brain.batchGet(ids, options?)`
+
+Batch retrieval of multiple entities (metadata-only by default).
+
+```typescript
+// Fetch multiple entities in a single batched operation
+const ids = ['id1', 'id2', 'id3']
+const results: Map<string, Entity> = await brain.batchGet(ids)
+
+// With vectors (falls back to individual gets)
+const resultsWithVectors = await brain.batchGet(ids, { includeVectors: true })
+
+// Results map
+results.get('id1') // → Entity or undefined
+results.size // → 3 (number of found entities)
+```
+
+**Performance:**
+- Memory storage: Instant (parallel reads)
+- Filesystem storage: Parallel reads, scales with available IOPS
+
+**Use Cases:**
+- Loading multiple entities for display
+- Bulk data export operations
+- Relationship traversal (fetch all connected entities)
+
+---
+
+## Storage-Level APIs
+
+### 2. `storage.getNounMetadataBatch(ids)`
+
+Batch metadata retrieval with direct O(1) path construction.
+
+```typescript
+const storage = brain.storage as BaseStorage
+const ids = ['id1', 'id2', 'id3']
+
+const metadataMap: Map<string, NounMetadata> = await storage.getNounMetadataBatch(ids)
+
+for (const [id, metadata] of metadataMap) {
+ console.log(metadata.noun) // Type: 'document', 'person', etc.
+ console.log(metadata.data) // Entity data
+}
+```
+
+**Features:**
+- ✅ Direct O(1) path construction from ID (no type lookup needed!)
+- ✅ Sharding preservation (all paths include `{shard}/{id}`)
+- ✅ Write-cache coherent (read-after-write consistency)
+- ✅ O(1) path construction — eliminates the per-entity type search of the old type-first layout
+
+**Performance:**
+- Constant-time path construction per ID — no type-cache misses
+- Filesystem: parallel reads bounded by IOPS
+- No type search delays — every ID maps directly to storage path
+
+---
+
+### 3. `storage.getVerbsBySourceBatch(sourceIds, verbType?)`
+
+Batch relationship queries by source entity IDs.
+
+```typescript
+const storage = brain.storage as BaseStorage
+
+// Get all relationships from multiple sources
+const results: Map<string, GraphVerb[]> = await storage.getVerbsBySourceBatch([
+ 'person1',
+ 'person2'
+])
+
+// Filter by verb type
+const createsResults = await storage.getVerbsBySourceBatch(
+ ['person1', 'person2'],
+ 'creates'
+)
+
+// Process results
+for (const [sourceId, verbs] of results) {
+ console.log(`${sourceId} has ${verbs.length} relationships`)
+ verbs.forEach(verb => {
+ console.log(` → ${verb.verb} → ${verb.targetId}`)
+ })
+}
+```
+
+**Use Cases:**
+- Social graph traversal (fetch all connections for multiple users)
+- Knowledge graph queries (find all relationships of specific type)
+- Bulk export of relationship data
+
+**Performance:**
+- Memory storage: single in-memory pass over the metadata index
+- Filesystem storage: parallel reads through the metadata index
+
+---
+
+## VFS Integration
+
+VFS operations automatically use batch APIs for maximum performance.
+
+### Directory Traversal
+
+```typescript
+// Tree traversal uses batched reads under the hood
+const tree = await brain.vfs.getTreeStructure('/my-dir')
+// ✅ PathResolver.getChildren() uses brain.batchGet() internally
+// ✅ Parallel traversal of directories at the same tree level
+// ✅ 2-3 batched calls instead of 22 sequential calls
+```
+
+**Architecture:**
+
+```
+VFS.getTreeStructure()
+ ↓ PARALLEL (breadth-first traversal)
+ → PathResolver.getChildren() [all dirs at level processed in parallel]
+ ↓ BATCHED
+ → brain.batchGet(childIds) [1 call instead of N]
+ ↓ BATCHED
+ → storage.getNounMetadataBatch(ids) [1 call instead of N]
+ ↓ ADAPTER
+ → Filesystem: Promise.all() parallel reads
+ → Memory: Promise.all() parallel reads
+```
+
+---
+
+## Advanced Features Compatibility
+
+### ✅ ID-First Storage Architecture
+
+All batch operations use direct ID-first paths - no type lookup needed!
+
+**ID-First Path Structure:**
+```
+entities/nouns/{SHARD}/{ID}/metadata.json
+entities/verbs/{SHARD}/{ID}/metadata.json
+```
+
+**Direct O(1) Path Construction:**
+```typescript
+// Every ID maps directly to exactly ONE path - O(1), no type search
+const id = 'abc-123'
+const shard = getShardIdFromUuid(id) // → 'ab' (first 2 hex chars)
+const path = `entities/nouns/${shard}/${id}/metadata.json`
+
+// No type cache needed!
+// No type search needed!
+// No multi-type fallback needed!
+// Just pure O(1) lookup!
+```
+
+**Benefits:**
+- **O(1)** path lookups (eliminates the 42-type sequential search the old type-first layout required)
+- **Simpler code** - removed 500+ lines of type cache complexity
+- **Scalable** - works at large scale without type tracking overhead
+
+---
+
+### ✅ Sharding
+
+All batch paths include shard IDs calculated via `getShardIdFromUuid(id)`:
+
+```typescript
+const id = 'a3c4e5f7-...'
+const shard = getShardIdFromUuid(id) // → 'a3' (first 2 hex chars)
+const path = `entities/nouns/${shard}/${id}/metadata.json`
+```
+
+**Distribution:** 256 shards (00-ff) for optimal load distribution.
+
+---
+
+### ✅ Generational MVCC (8.0)
+
+Batch reads always serve the **live** generation through the fast paths
+shown above. Point-in-time reads go through the Db API instead: a pinned
+`Db` (`brain.now()`, `brain.asOf()`) resolves changed ids from immutable
+generation records and unchanged ids from the same live paths batch reads
+use — see the [consistency model](concepts/consistency-model.md).
+
+```typescript
+const db = brain.now()                       // pinned view
+const entity = await db.get(id)              // correct at the pinned generation
+const results = await brain.batchGet(ids)    // live state, batched
+await db.release()
+```
+
+---
+
+## Why Batching Is Faster
+
+Batching's advantage is structural, not a fixed multiplier (the actual speedup
+depends on storage backend, IOPS, and batch size):
+
+- **N+1 elimination** — N sequential reads collapse into a single parallel pass
+  (`Promise.all` over the batch).
+- **O(1) path construction** — every ID maps directly to one storage path, with
+  no per-type cache lookup.
+- **One metadata round-trip** — relationship batches fetch all sources' metadata
+  in a single pass instead of one query per source.
+
+The integration test `tests/integration/storage-batch-operations.test.ts`
+exercises batch vs. individual reads and asserts that batch retrieval is not
+slower than the per-entity loop for large batches; it does not pin a specific
+multiplier, since that is hardware- and IOPS-dependent.
+
+---
+
+## Error Handling
+
+### Partial Batch Failures
+
+Batch operations gracefully handle missing or invalid entities:
+
+```typescript
+const validId = 'abc-123-...'
+const invalidIds = [
+ '11111111-1111-1111-1111-111111111111',
+ '22222222-2222-2222-2222-222222222222'
+]
+
+const results = await brain.batchGet([validId, ...invalidIds])
+
+results.size // → 1 (only valid entity)
+results.has(validId) // → true
+results.has(invalidIds[0]) // → false (silently skipped)
+```
+
+**Behavior:**
+- Invalid UUIDs: Silently skipped (not included in results)
+- Missing entities: Silently skipped (not included in results)
+- Storage errors: Logged, entity excluded from results
+- No exceptions thrown for partial failures
+
+### Empty Batches
+
+```typescript
+const results = await brain.batchGet([])
+results.size // → 0 (empty map)
+```
+
+### Duplicate IDs
+
+```typescript
+const results = await brain.batchGet(['id1', 'id1', 'id1'])
+results.size // → 1 (deduplicated automatically)
+```
+
+---
+
+## Migration Guide
+
+### From Individual Gets
+
+**Before:**
+```typescript
+const entities = []
+for (const id of ids) {
+ const entity = await brain.get(id)
+ if (entity) entities.push(entity)
+}
+```
+
+**After:**
+```typescript
+const results = await brain.batchGet(ids)
+const entities = Array.from(results.values())
+```
+
+**Performance Gain:** Replaces N sequential reads with a single batched pass — no fixed multiplier, it scales with storage IOPS.
+
+---
+
+### From Individual Relationship Queries
+
+**Before:**
+```typescript
+const allVerbs = []
+for (const sourceId of sourceIds) {
+ const verbs = await brain.related({ from: sourceId })
+ allVerbs.push(...verbs)
+}
+```
+
+**After:**
+```typescript
+const storage = brain.storage as BaseStorage
+const results = await storage.getVerbsBySourceBatch(sourceIds)
+
+const allVerbs = []
+for (const verbs of results.values()) {
+ allVerbs.push(...verbs)
+}
+```
+
+**Performance Gain:** One batched metadata fetch instead of one query per source entity.
+
+---
+
+## Best Practices
+
+### 1. **Use Batching for Multiple Entity Operations**
+
+```typescript
+// ✅ GOOD: Batch fetch
+const results = await brain.batchGet(ids)
+
+// ❌ BAD: Individual gets in loop
+for (const id of ids) {
+ await brain.get(id)
+}
+```
+
+### 2. **Batch Size Recommendations**
+
+| Storage | Optimal Batch Size | Max Batch Size |
+|---------|--------------------|----------------|
+| **Memory** | Unlimited | Unlimited |
+| **Filesystem** | 100-500 | 1000 |
+
+**Guideline:** For batches >1000, split into chunks of 500-1000.
+
+### 3. **Metadata-Only by Default**
+
+```typescript
+// Default: Metadata-only (fast)
+const results = await brain.batchGet(ids) // No vectors
+
+// Only load vectors if needed
+const withVectors = await brain.batchGet(ids, { includeVectors: true })
+```
+
+### 4. **Error Handling**
+
+```typescript
+// Batch operations never throw for missing entities
+const results = await brain.batchGet(ids)
+
+// Check results
+for (const id of ids) {
+ if (results.has(id)) {
+ // Entity exists
+ const entity = results.get(id)
+ } else {
+ // Entity missing (not an error)
+ console.log(`Entity ${id} not found`)
+ }
+}
+```
+
+---
+
+## Testing
+
+Comprehensive test coverage in `tests/integration/storage-batch-operations.test.ts`:
+
+```bash
+npx vitest run tests/integration/storage-batch-operations.test.ts
+```
+
+**Test Coverage:**
+- ✅ brain.batchGet() high-level API
+- ✅ storage.getNounMetadataBatch() with ID-first paths
+- ✅ COW integration (branch isolation, inheritance)
+- ✅ storage.getVerbsBySourceBatch() relationship queries
+- ✅ VFS integration (PathResolver.getChildren())
+- ✅ Performance benchmarks (N+1 elimination)
+- ✅ Error handling (partial failures, empty batches, duplicates)
+- ✅ ID-first storage verification
+- ✅ Sharding preservation
+
+**Results:** 23 tests passing ✅
+
+---
+
+## Implementation Details
+
+### Architecture Layers
+
+```
+User Code (brain.batchGet)
+ ↓
+High-Level API (src/brainy.ts)
+ ↓
+Storage Layer (src/storage/baseStorage.ts)
+ ↓
+Adapter Layer (readBatchFromAdapter)
+ ↓
+Storage Adapter (FileSystemStorage / MemoryStorage)
+```
+
+### Parallel Reads
+
+Both shipped adapters fall back to `Promise.all` over individual reads:
+
+```typescript
+// BaseStorage.readBatchFromAdapter()
+return await Promise.all(resolvedPaths.map(path => this.read(path)))
+```
+
+**Shipped Adapters:**
+- MemoryStorage
+- FileSystemStorage
+
+---
+
+## API Summary
+
+- `brain.batchGet(ids, options?)` - High-level batch entity retrieval
+- `storage.getNounMetadataBatch(ids)` - Storage-level metadata batch
+- `storage.getVerbsBySourceBatch(sourceIds, verbType?)` - Batch relationship queries
+
+**Performance Improvements:**
+- VFS operations: single batched pass instead of N sequential reads
+- Entity retrieval: N+1 reads collapsed into one batched pass
+- Zero N+1 query patterns
+
+**Compatibility:**
+- ✅ ID-first storage
+- ✅ Sharding (256 shards)
+- ✅ Generational MVCC — batch reads serve the live generation; pinned `Db` views serve the past
+- ✅ All indexes respected (vector, metadata, graph adjacency)
+
+---
+
+## Support
+
+- **Documentation:** `/docs/BATCHING.md`, `/docs/PERFORMANCE.md`
+- **Tests:** `/tests/integration/storage-batch-operations.test.ts`
+- **Issues:** https://github.com/soulcraft/brainy/issues
+- **Discussions:** https://github.com/soulcraft/brainy/discussions
+
+---
+
+**Built with ❤️ for enterprise-scale knowledge graphs**

docs/DATA_MODEL.md

@@ -0,0 +1,271 @@
+# Data Model
+
+> How Brainy stores entities and relationships, and the critical distinction between `data` and `metadata`.
+
+---
+
+## Entity (Noun)
+
+An entity is the fundamental data unit in Brainy. Every entity has:
+
+| Field | Type | Indexed | Description |
+|-------|------|---------|-------------|
+| `id` | `string` | Primary key | UUID v4 (auto-generated or custom) |
+| `data` | `any` | **HNSW vector index** | Content used for semantic/hybrid search. Strings auto-embed. |
+| `metadata` | `object` | **MetadataIndex** | Structured queryable fields (tags, dates, flags, etc.) |
+| `type` | `NounType` | MetadataIndex (as `noun`) | Entity type classification |
+| `vector` | `number[]` | HNSW | 384-dim embedding (auto-computed from `data` or user-provided) |
+| `confidence` | `number` | MetadataIndex | Type classification confidence (0-1) |
+| `weight` | `number` | MetadataIndex | Entity importance/salience (0-1) |
+| `service` | `string` | MetadataIndex | Multi-tenancy identifier |
+| `createdAt` | `number` | MetadataIndex | Creation timestamp (ms since epoch) |
+| `updatedAt` | `number` | MetadataIndex | Last update timestamp (ms since epoch) |
+| `createdBy` | `object` | MetadataIndex | Source augmentation info |
+
+### Example
+
+```typescript
+const id = await brain.add({
+  data: 'John Smith is a software engineer at Acme Corp',  // → embedded into vector
+  type: NounType.Person,
+  metadata: {                   // → indexed, queryable via where filters
+    role: 'engineer',
+    department: 'backend',
+    yearsExperience: 8
+  },
+  confidence: 0.95,
+  weight: 0.7
+})
+```
+
+---
+
+## Relationship (Verb)
+
+A relationship is a typed, directed edge connecting two entities.
+
+| Field | Type | Indexed | Description |
+|-------|------|---------|-------------|
+| `id` | `string` | Primary key | UUID v4 (auto-generated) |
+| `from` | `string` | **GraphAdjacencyIndex** | Source entity ID |
+| `to` | `string` | **GraphAdjacencyIndex** | Target entity ID |
+| `type` | `VerbType` | GraphAdjacencyIndex (as `verb`) | Relationship type classification |
+| `data` | `any` | — | Opaque content (overrides auto-computed vector if provided) |
+| `metadata` | `object` | — | Structured fields on the edge |
+| `weight` | `number` | — | Connection strength (0-1, default: 1.0) |
+| `confidence` | `number` | — | Relationship certainty (0-1) |
+| `evidence` | `RelationEvidence` | — | Why this relationship was detected |
+| `createdAt` | `number` | — | Creation timestamp (ms since epoch) |
+| `updatedAt` | `number` | — | Last update timestamp (ms since epoch) |
+| `service` | `string` | — | Multi-tenancy identifier |
+
+### Example
+
+```typescript
+const relId = await brain.relate({
+  from: personId,
+  to: projectId,
+  type: VerbType.WorksOn,
+  data: 'Lead engineer on the AI module',   // Optional: content for this edge
+  metadata: {                                // Optional: queryable edge fields
+    role: 'lead',
+    startDate: '2024-01-15'
+  },
+  weight: 0.9
+})
+```
+
+---
+
+## Data vs Metadata
+
+This is the most important concept in Brainy's storage model:
+
+### `data` — Content for Semantic Search
+
+- Embedded into a 384-dimensional vector via the WASM embedding engine
+- Searchable via **semantic similarity** (HNSW vector index) and **hybrid text+semantic** search
+- Queried by passing `query` to `find()`:
+  ```typescript
+  brain.find({ query: 'machine learning algorithms' })
+  ```
+- **NOT** indexed by MetadataIndex — you cannot use `where` filters on `data`
+- Stored opaquely: strings, objects, numbers — anything goes
+
+### `metadata` — Structured Queryable Fields
+
+- Indexed by MetadataIndex with O(1) lookups per field
+- Queryable via `where` filters using [BFO operators](./QUERY_OPERATORS.md):
+  ```typescript
+  brain.find({
+    where: {
+      department: 'engineering',
+      yearsExperience: { greaterThan: 5 },
+      tags: { contains: 'senior' }
+    }
+  })
+  ```
+- **NOT** used for vector/semantic search
+- Must be a flat or lightly nested object
+
+### Quick Reference
+
+| | `data` | `metadata` |
+|---|---|---|
+| **Purpose** | Content for embedding / semantic search | Structured fields for filtering |
+| **Searched by** | `find({ query })` — vector similarity, hybrid text+semantic | `find({ where })` — exact, range, set operators |
+| **Indexed by** | HNSW vector index | MetadataIndex |
+| **Queryable with operators?** | No | Yes (`equals`, `greaterThan`, `oneOf`, etc.) |
+| **Auto-embedded?** | Yes (strings → 384-dim vectors) | No |
+| **Typical content** | Text descriptions, document content | Tags, dates, status flags, categories, numeric fields |
+
+### Common Pattern
+
+```typescript
+// Add an article
+await brain.add({
+  data: 'A deep dive into transformer architectures and attention mechanisms',
+  type: NounType.Document,
+  metadata: {
+    title: 'Transformer Deep Dive',
+    author: 'Dr. Chen',
+    publishedYear: 2024,
+    tags: ['AI', 'transformers', 'NLP'],
+    status: 'published'
+  }
+})
+
+// Search by content (semantic — searches data)
+const results = await brain.find({ query: 'neural network attention' })
+
+// Filter by fields (exact — queries metadata)
+const recent = await brain.find({
+  where: {
+    publishedYear: { greaterThan: 2023 },
+    status: 'published'
+  }
+})
+
+// Combine both (Triple Intelligence)
+const precise = await brain.find({
+  query: 'attention mechanisms',             // Semantic search on data
+  where: { author: 'Dr. Chen' },            // Metadata filter
+  connected: { from: authorId, depth: 1 }   // Graph traversal
+})
+```
+
+---
+
+## Storage Field Naming
+
+Internally, Brainy uses different field names in storage vs the public API:
+
+| Public API (Entity/Relation) | Storage (metadata object) | Notes |
+|------------------------------|--------------------------|-------|
+| `type` | `noun` | Entity type stored as `noun` |
+| `from` | `sourceId` | Relationship source |
+| `to` | `targetId` | Relationship target |
+| `type` (on Relation) | `verb` | Relationship type stored as `verb` |
+
+When querying with `find()`, you can use:
+- `type` parameter (convenience alias, equivalent to `where.noun`)
+- `where.noun` directly
+
+```typescript
+// These are equivalent:
+brain.find({ type: NounType.Person })
+brain.find({ where: { noun: NounType.Person } })
+```
+
+---
+
+## Standard Metadata Fields
+
+When you add an entity, Brainy stores these standard fields in the metadata object alongside your custom fields:
+
+| Field | Set By | Description |
+|-------|--------|-------------|
+| `noun` | System | Entity type (NounType enum value) |
+| `subtype` | User | Per-NounType sub-classification (e.g. `'employee'`, `'invoice'`, `'milestone'`). Flat string, no hierarchy. Indexed on the fast path and rolled into per-NounType statistics. |
+| `data` | System | The raw `data` value (stored opaquely) |
+| `createdAt` | System | Creation timestamp |
+| `updatedAt` | System | Last update timestamp |
+| `confidence` | User | Type classification confidence |
+| `weight` | User | Entity importance |
+| `service` | User | Multi-tenancy identifier |
+| `createdBy` | User/System | Source augmentation |
+
+On read, these standard fields are extracted to top-level Entity properties. The `metadata` field on the returned Entity contains **only your custom fields**.
+
+### Subtype — sub-classification within a NounType
+
+`type` (NounType) is a stable 42-value enum. `subtype` is the consumer-chosen string vocabulary *within* a type:
+
+```typescript
+// A Person who is an employee:
+await brain.add({
+  data: 'Avery Brooks — runs the AI lab',
+  type: NounType.Person,
+  subtype: 'employee',
+  metadata: { department: 'ai-lab' }
+})
+
+// A Document that is an invoice:
+await brain.add({
+  data: 'INV-2026-001',
+  type: NounType.Document,
+  subtype: 'invoice',
+  metadata: { amount: 1500 }
+})
+```
+
+`subtype` lives at the **top level** — NOT inside `metadata`, NOT inside `data`. That's how `find({ type, subtype })` routes through the standard-field fast path (column-store hit) instead of the metadata fallback. See **[Subtypes & Facets](./guides/subtypes-and-facets.md)** for the full guide including `trackField()` and `migrateField()`.
+
+### Subtype — sub-classification within a VerbType (7.30+)
+
+Relationships are first-class citizens too. Every verb (`VerbType`) gets the same `subtype` primitive — a `ReportsTo` relationship might carry `subtype: 'direct'` vs `'dotted-line'`; a `RelatedTo` edge might carry `'spouse'` / `'sibling'` / `'colleague'`. Same shape as the noun side: flat string, no hierarchy, top-level standard field on `HNSWVerbWithMetadata` and on the public `Relation<T>`:
+
+```typescript
+await brain.relate({
+  from: ceoId,
+  to: vpId,
+  type: VerbType.ReportsTo,
+  subtype: 'direct',                  // top-level standard field
+  metadata: { since: '2025-Q1' }      // user-custom fields stay in metadata
+})
+```
+
+Fast-path filter on the verb side:
+
+```typescript
+const direct = await brain.related({
+  from: ceoId,
+  type: VerbType.ReportsTo,
+  subtype: 'direct'
+})
+```
+
+The verb-side rollup at `_system/verb-subtype-statistics.json` mirrors the noun-side `_system/subtype-statistics.json` — same shape, same self-heal machinery. Per-VerbType-per-subtype counts are O(1) via `brain.counts.byRelationshipSubtype()`.
+
+Verbs and nouns now have full capability parity — every API on the noun side has a verb-side mirror, including the new `brain.updateRelation()` (which closed a pre-7.30 gap where relationships had no update path).
+
+### Standard verb fields
+
+The verb-side equivalent of `STANDARD_ENTITY_FIELDS` is `STANDARD_VERB_FIELDS`, exported from `src/coreTypes.ts`. Verb-specific standard fields:
+
+| Field | Description |
+|---|---|
+| `verb` | The VerbType enum value |
+| `sourceId` / `targetId` | The two endpoints of the relationship |
+| `subtype` | Sub-classification within the VerbType (7.30+) |
+| `confidence`, `weight`, `createdAt`, `updatedAt`, `service`, `createdBy`, `data` | Same semantics as the noun-side standard fields |
+
+The companion `resolveVerbField(verb, field)` helper resolves field paths the same way `resolveEntityField` does for nouns: standard fields first, metadata fallback for everything else.
+
+---
+
+## See Also
+
+- [API Reference](./api/README.md) — Complete API documentation
+- [Query Operators](./QUERY_OPERATORS.md) — All BFO operators with examples
+- [Find System](./FIND_SYSTEM.md) — Natural language find() details

docs/MIGRATION-V3-TO-V4.md

@@ -0,0 +1,569 @@
+# Brainy v3 → v4.0.0 Migration Guide
+
+> **Migration Complexity**: Low
+> **Breaking Changes**: None (fully backward compatible)
+> **New Features**: Lifecycle management, batch operations, compression, quota monitoring
+
+## Overview
+
+Brainy v4.0.0 is a **backward-compatible** release focused on production-ready cost optimization features. Your existing v3 code will continue to work without modifications, but you'll want to enable the new v4.0.0 features for significant cost savings.
+
+**Key Benefits of Upgrading:**
+- 💰 **96% cost savings** with lifecycle policies
+- 🚀 **1000x faster** bulk deletions with batch operations
+- 📦 **60-80% space savings** with gzip compression
+- 📊 **Real-time quota monitoring** for OPFS
+- 🎯 **Zero downtime** migration
+
+## What's New in v4.0.0
+
+### 1. Lifecycle Management (Cloud Storage)
+
+**Automatic tier transitions for massive cost savings:**
+
+```typescript
+// NEW in v4.0.0
+await storage.setLifecyclePolicy({
+  rules: [{
+    id: 'archive-old-data',
+    prefix: 'entities/',
+    status: 'Enabled',
+    transitions: [
+      { days: 30, storageClass: 'STANDARD_IA' },
+      { days: 90, storageClass: 'GLACIER' }
+    ]
+  }]
+})
+```
+
+**Supported on:**
+- ✅ AWS S3 (Lifecycle + Intelligent-Tiering)
+- ✅ Google Cloud Storage (Lifecycle + Autoclass)
+- ✅ Azure Blob Storage (Lifecycle policies)
+
+### 2. Batch Operations
+
+**1000x faster bulk deletions:**
+
+```typescript
+// v3: Delete one at a time (slow, expensive)
+for (const id of idsToDelete) {
+  await brain.remove(id)  // 1000 API calls for 1000 entities
+}
+
+// v4.0.0: Batch delete (fast, cheap)
+const paths = idsToDelete.flatMap(id => [
+  `entities/nouns/vectors/${id.substring(0, 2)}/${id}.json`,
+  `entities/nouns/metadata/${id.substring(0, 2)}/${id}.json`
+])
+await storage.batchDelete(paths)  // 1 API call for 1000 objects (S3)
+```
+
+**Efficiency gains:**
+- S3: 1000 objects per batch
+- GCS: 100 objects per batch
+- Azure: 256 objects per batch
+
+### 3. Compression (FileSystem)
+
+**60-80% space savings for local storage:**
+
+```typescript
+// NEW in v4.0.0
+const brain = new Brainy({
+  storage: {
+    type: 'filesystem',
+    path: './data',
+    compression: true  // Enable gzip compression
+  }
+})
+
+// Automatic compression/decompression on all reads/writes
+```
+
+### 4. Quota Monitoring (OPFS)
+
+**Prevent quota exceeded errors in browsers:**
+
+```typescript
+// NEW in v4.0.0
+const status = await storage.getStorageStatus()
+
+if (status.details.usagePercent > 80) {
+  console.warn('Approaching quota limit:', status.details)
+  // Take action: cleanup old data, notify user, etc.
+}
+```
+
+### 5. Tier Management (Azure)
+
+**Manual or automatic tier transitions:**
+
+```typescript
+// NEW in v4.0.0
+await storage.changeBlobTier(blobPath, 'Cool')  // Hot → Cool (50% savings)
+await storage.batchChangeTier([blob1, blob2], 'Archive')  // 99% savings
+
+// Rehydrate from Archive when needed
+await storage.rehydrateBlob(blobPath, 'High')  // 1-hour rehydration
+```
+
+## Storage Architecture Changes
+
+### v3.x Storage Structure
+
+```
+brainy-data/
+├── nouns/
+│   └── {uuid}.json          # Single file per entity
+├── verbs/
+│   └── {uuid}.json          # Single file per relationship
+├── metadata/
+│   └── __metadata_*.json    # Indexes
+└── _system/
+    └── statistics.json
+```
+
+### v4.0.0 Storage Structure (Automatic Migration)
+
+```
+brainy-data/
+├── entities/
+│   ├── nouns/
+│   │   ├── vectors/         # Vector + HNSW graph (NEW)
+│   │   │   ├── 00/ ... ff/  # 256 UUID shards (NEW)
+│   │   └── metadata/        # Business data (NEW)
+│   │       ├── 00/ ... ff/  # 256 UUID shards (NEW)
+│   └── verbs/
+│       ├── vectors/         # Relationship vectors (NEW)
+│       │   ├── 00/ ... ff/
+│       └── metadata/        # Relationship data (NEW)
+│           ├── 00/ ... ff/
+└── _system/                 # Unchanged
+    └── __metadata_*.json
+```
+
+**Key Changes:**
+1. **Metadata/Vector Separation**: Entities split into 2 files for optimal I/O
+2. **UUID-Based Sharding**: 256 shards for cloud storage optimization
+3. **Automatic Migration**: Brainy handles migration transparently on first run
+
+## Migration Steps
+
+### Step 1: Update Brainy Package
+
+```bash
+npm install @soulcraft/brainy@latest
+```
+
+**Check your version:**
+```bash
+npm list @soulcraft/brainy
+# Should show: @soulcraft/brainy@4.0.0
+```
+
+### Step 2: No Code Changes Required! ✅
+
+Your existing v3 code will work without modifications:
+
+```typescript
+// This v3 code works perfectly in v4.0.0
+const brain = new Brainy({
+  storage: { type: 'filesystem', path: './data' }
+})
+
+await brain.init()
+await brain.add("content", { type: "entity" })
+const results = await brain.search("query")
+```
+
+### Step 3: First Run (Automatic Migration)
+
+On first initialization with v4.0.0:
+
+1. **Brainy detects v3 storage structure**
+2. **Transparently migrates to v4.0.0 structure**:
+   - Creates `entities/` directory
+   - Migrates `nouns/` → `entities/nouns/vectors/` + `entities/nouns/metadata/`
+   - Migrates `verbs/` → `entities/verbs/vectors/` + `entities/verbs/metadata/`
+   - Applies UUID-based sharding
+3. **Old structure preserved** (optional cleanup later)
+
+**Migration time:**
+- 10K entities: ~1 minute
+- 100K entities: ~10 minutes
+- 1M entities: ~2 hours
+
+**Zero downtime:**
+- Migration happens during init()
+- No data loss
+- Automatic rollback on error
+
+### Step 4: Enable v4.0.0 Features (Optional but Recommended)
+
+#### Enable Lifecycle Policies (Cloud Storage)
+
+**AWS S3:**
+```typescript
+// After init()
+await storage.setLifecyclePolicy({
+  rules: [{
+    id: 'optimize-storage',
+    prefix: 'entities/',
+    status: 'Enabled',
+    transitions: [
+      { days: 30, storageClass: 'STANDARD_IA' },
+      { days: 90, storageClass: 'GLACIER' }
+    ]
+  }]
+})
+
+// Or use Intelligent-Tiering (recommended)
+await storage.enableIntelligentTiering('entities/', 'auto-optimize')
+```
+
+**Google Cloud Storage:**
+```typescript
+await storage.enableAutoclass({
+  terminalStorageClass: 'ARCHIVE'
+})
+```
+
+**Azure Blob Storage:**
+```typescript
+await storage.setLifecyclePolicy({
+  rules: [{
+    name: 'optimize-blobs',
+    enabled: true,
+    type: 'Lifecycle',
+    definition: {
+      filters: { blobTypes: ['blockBlob'] },
+      actions: {
+        baseBlob: {
+          tierToCool: { daysAfterModificationGreaterThan: 30 },
+          tierToArchive: { daysAfterModificationGreaterThan: 90 }
+        }
+      }
+    }
+  }]
+})
+```
+
+#### Enable Compression (FileSystem)
+
+```typescript
+const brain = new Brainy({
+  storage: {
+    type: 'filesystem',
+    path: './data',
+    compression: true  // NEW: 60-80% space savings
+  }
+})
+```
+
+#### Use Batch Operations
+
+```typescript
+// Replace individual deletes with batch delete
+const idsToDelete = [/* ... */]
+const paths = idsToDelete.flatMap(id => {
+  const shard = id.substring(0, 2)
+  return [
+    `entities/nouns/vectors/${shard}/${id}.json`,
+    `entities/nouns/metadata/${shard}/${id}.json`
+  ]
+})
+
+await storage.batchDelete(paths)  // Much faster!
+```
+
+#### Monitor Quota (OPFS)
+
+```typescript
+// Periodically check quota in browser apps
+setInterval(async () => {
+  const status = await storage.getStorageStatus()
+  if (status.details.usagePercent > 80) {
+    notifyUser('Storage approaching limit')
+  }
+}, 60000)  // Check every minute
+```
+
+## Backward Compatibility
+
+### Guaranteed to Work (No Changes Needed)
+
+✅ All v3 APIs remain unchanged
+✅ Storage adapters backward compatible
+✅ Metadata structure unchanged
+✅ Query APIs unchanged
+✅ Configuration options unchanged
+
+### New Optional APIs (Add When Ready)
+
+- `storage.setLifecyclePolicy()` - NEW in v4.0.0
+- `storage.getLifecyclePolicy()` - NEW in v4.0.0
+- `storage.removeLifecyclePolicy()` - NEW in v4.0.0
+- `storage.enableIntelligentTiering()` - NEW in v4.0.0 (S3)
+- `storage.enableAutoclass()` - NEW in v4.0.0 (GCS)
+- `storage.batchDelete()` - NEW in v4.0.0
+- `storage.changeBlobTier()` - NEW in v4.0.0 (Azure)
+- `storage.getStorageStatus()` - Enhanced in v4.0.0
+
+## Testing Your Migration
+
+### 1. Test in Development First
+
+```typescript
+// Create test brain with v4.0.0
+const testBrain = new Brainy({
+  storage: { type: 'filesystem', path: './test-data' }
+})
+
+await testBrain.init()
+
+// Verify migration
+console.log('Initialization complete')
+
+// Test basic operations
+const id = await testBrain.add("test content", { type: "test" })
+const results = await testBrain.search("test")
+console.log('Basic operations working:', results.length > 0)
+```
+
+### 2. Verify Storage Structure
+
+```bash
+# Check new directory structure
+ls -la ./test-data/entities/nouns/vectors/
+# Should see: 00/ 01/ 02/ ... ff/ (256 shards)
+
+ls -la ./test-data/entities/nouns/metadata/
+# Should see: 00/ 01/ 02/ ... ff/ (256 shards)
+```
+
+### 3. Verify Data Integrity
+
+```typescript
+// Query all entities
+const allEntities = await testBrain.find({})
+console.log('Total entities:', allEntities.length)
+
+// Verify specific entities
+const entity = await testBrain.get(knownEntityId)
+console.log('Entity retrieved:', entity !== null)
+```
+
+### 4. Test Performance
+
+```typescript
+// Benchmark search
+const start = Date.now()
+const results = await testBrain.search("query")
+const duration = Date.now() - start
+console.log('Search time:', duration, 'ms')
+
+// Should be similar or faster than v3
+```
+
+## Rollback Procedure (If Needed)
+
+If you encounter issues, you can rollback:
+
+### Option 1: Rollback Package
+
+```bash
+# Reinstall v3
+npm install @soulcraft/brainy@^3.50.0
+
+# Restart application
+```
+
+**Important:** v3 can still read v3-structured data (preserved during migration)
+
+### Option 2: Restore from Backup
+
+```bash
+# If you backed up data before migration
+rm -rf ./data
+cp -r ./data-backup ./data
+
+# Reinstall v3
+npm install @soulcraft/brainy@^3.50.0
+```
+
+## Common Migration Scenarios
+
+### Scenario 1: Small Application (<10K Entities)
+
+**Migration time:** 1 minute
+**Recommended approach:**
+1. Update npm package
+2. Restart application (automatic migration)
+3. Enable lifecycle policies immediately
+
+### Scenario 2: Medium Application (10K-1M Entities)
+
+**Migration time:** 10 minutes - 2 hours
+**Recommended approach:**
+1. Backup data
+2. Update npm package
+3. Schedule maintenance window
+4. Restart application (automatic migration)
+5. Verify data integrity
+6. Enable lifecycle policies
+
+### Scenario 3: Large Application (1M+ Entities)
+
+**Migration time:** 2-24 hours
+**Recommended approach:**
+1. **Backup data** (critical!)
+2. Test migration on staging environment
+3. Schedule extended maintenance window
+4. Update npm package on production
+5. Restart application (automatic migration)
+6. Monitor migration progress
+7. Verify data integrity thoroughly
+8. Enable lifecycle policies gradually
+
+## Cost Savings After Migration
+
+### Enable All v4.0.0 Features
+
+**500TB Dataset Example:**
+
+**Before v4.0.0 (v3 with AWS S3 Standard):**
+```
+Storage: $138,000/year
+Operations: $5,000/year
+Total: $143,000/year
+```
+
+**After v4.0.0 (with Intelligent-Tiering):**
+```
+Storage: $51,000/year (64% savings)
+Operations: $5,000/year
+Total: $56,000/year
+```
+
+**After v4.0.0 (with Lifecycle Policies):**
+```
+Storage: $5,940/year (96% savings!)
+Operations: $5,000/year
+Total: $10,940/year
+```
+
+**Annual Savings: $132,060 (96% reduction)**
+
+## Troubleshooting
+
+### Issue: Migration takes too long
+
+**Solution:**
+- Migration is I/O bound
+- For 1M+ entities, consider:
+  - Running during off-peak hours
+  - Using faster storage (SSD vs HDD)
+  - Increasing available memory
+  - Running on more powerful instance
+
+### Issue: "Storage structure not recognized"
+
+**Solution:**
+```typescript
+// Manually trigger migration
+await brain.storage.migrateToV4()  // If automatic migration fails
+
+// Or start fresh (data loss warning!)
+await brain.storage.clear()
+await brain.init()
+```
+
+### Issue: Lifecycle policy not working
+
+**Solution:**
+```typescript
+// Verify policy is set
+const policy = await storage.getLifecyclePolicy()
+console.log('Active rules:', policy.rules)
+
+// Cloud providers may take 24-48 hours to start transitions
+// Check again after 2 days
+
+// Verify in cloud console:
+// - AWS: S3 → Bucket → Management → Lifecycle
+// - GCS: Storage → Bucket → Lifecycle
+// - Azure: Storage Account → Lifecycle management
+```
+
+### Issue: Batch delete not working
+
+**Solution:**
+```typescript
+// Ensure storage adapter supports batch delete
+const status = await storage.getStorageStatus()
+console.log('Storage type:', status.type)
+
+// Batch delete requires:
+// - S3CompatibleStorage ✅
+// - GcsStorage ✅
+// - AzureBlobStorage ✅
+// - FileSystemStorage ✅
+// - OPFSStorage ✅
+// - MemoryStorage ✅
+```
+
+## Best Practices
+
+1. ✅ **Backup before upgrading** (especially for large datasets)
+2. ✅ **Test on staging first** (verify migration works)
+3. ✅ **Monitor during migration** (watch logs for errors)
+4. ✅ **Enable lifecycle policies immediately** (start saving costs)
+5. ✅ **Use batch operations** (for any bulk cleanup)
+6. ✅ **Monitor quota** (OPFS browser apps)
+7. ✅ **Enable compression** (FileSystem storage)
+
+## Getting Help
+
+**Documentation:**
+- [AWS S3 Cost Optimization Guide](./operations/cost-optimization-aws-s3.md)
+- [GCS Cost Optimization Guide](./operations/cost-optimization-gcs.md)
+- [Azure Cost Optimization Guide](./operations/cost-optimization-azure.md)
+- [Cloudflare R2 Cost Optimization Guide](./operations/cost-optimization-cloudflare-r2.md)
+
+**Support:**
+- GitHub Issues: [https://github.com/soulcraft/brainy/issues](https://github.com/soulcraft/brainy/issues)
+- GitHub Discussions: [https://github.com/soulcraft/brainy/discussions](https://github.com/soulcraft/brainy/discussions)
+
+## Summary
+
+**Migration Checklist:**
+- ✅ Backup data
+- ✅ Update npm package (`npm install @soulcraft/brainy@latest`)
+- ✅ Restart application (automatic migration)
+- ✅ Verify data integrity
+- ✅ Enable lifecycle policies
+- ✅ Enable compression (FileSystem)
+- ✅ Use batch operations
+- ✅ Monitor cost savings
+
+**Expected Results:**
+- ✅ Zero downtime migration
+- ✅ Full backward compatibility
+- ✅ 60-96% cost savings
+- ✅ 1000x faster bulk operations
+- ✅ 60-80% space savings (with compression)
+
+**Timeline:**
+- Small app (<10K): 1 minute migration
+- Medium app (10K-1M): 10 minutes - 2 hours
+- Large app (1M+): 2-24 hours
+
+**Welcome to Brainy v4.0.0! 🎉**
+
+---
+
+**Version**: v4.0.0
+**Migration Difficulty**: Low
+**Breaking Changes**: None
+**Recommended Upgrade**: Yes (significant cost savings)

docs/PERFORMANCE.md

@@ -0,0 +1,492 @@
+# Brainy Performance & Architecture
+
+## Performance Characteristics
+
+Brainy achieves high performance through carefully optimized data structures and algorithms. The tables below describe each component by its **algorithmic complexity** — the durable, defensible guarantee. The example latencies are figures from a single 100-item run on one machine (see [Benchmarks](#benchmarks)); they are illustrative, not a committed benchmark, and vary with hardware, embedding model, and storage backend. The one component with a committed scale assertion is the graph adjacency index (`tests/performance/graph-scale-performance.test.ts:238`).
+
+### Core Performance Summary
+
+| Component | Operation | Time Complexity | Example latency (100-item run)\* | Data Structure |
+|-----------|-----------|-----------------|---------------------|----------------|
+| **Metadata Index** | Exact match | **O(1)** | 0.8ms | `Map<string, Set<string>>` |
+| **Metadata Index** | Range query | **O(log n) + O(k)** | 0.6ms | Sorted array + binary search |
+| **Graph Index** | Get neighbors | **O(1)** | 0.09ms | `Map<string, Set<string>>` |
+| **Vector Search** | k-NN search | **O(log n)** | 1.8ms | Hierarchical graph |
+| **NLP Parser** | Query parsing | **O(m)** | 8.9ms | 220 pre-computed patterns |
+| **Type-Field Affinity** | Field matching | **O(f)** | 0.1ms | Type-specific field cache |
+| **Type Detection** | Noun/Verb matching | **O(t)** | 0.3ms | Pre-embedded type vectors |
+| **Triple Intelligence** | Combined query | **O(1) to O(log n)** | 1.8ms | Parallel execution |
+
+\* Illustrative single-run figures at 100 items on one machine — not a committed benchmark. Only the graph index carries an asserted scale bound (measured <1 ms per neighbor lookup up to 1M relationships, `tests/performance/graph-scale-performance.test.ts:238`).
+
+Where:
+- `n` = number of items in index
+- `k` = number of results returned
+- `m` = number of patterns to check
+- `f` = number of fields for entity type
+- `t` = number of types (42 nouns, 127 verbs)
+
+### brain.get() Metadata-Only Optimization
+
+`brain.get()` returns **metadata only by default**, skipping the 384-dimensional
+embedding — the bulk of an entity's payload. Callers that need the vector opt in
+with `{ includeVectors: true }`.
+
+| Operation | Default (metadata-only) | With `includeVectors: true` | Use Case |
+|-----------|-------------------------|-----------------------------|----------|
+| **brain.get()** | Skips vector load | Loads full vector | VFS, existence checks, metadata |
+| **VFS readFile() / readdir()** | Inherits metadata-only path | n/a | File operations, directory listings |
+
+**Key Innovation**: Lazy vector loading — only load the 384-dimensional embedding when explicitly needed.
+
+The integration test `tests/integration/metadata-only-comprehensive.test.ts:306`
+asserts metadata-only `get()` is faster than the full-entity `get()`
+(`metadataTime < fullTime`). The *magnitude* of the speedup is
+environment-dependent (the percentage assertion in
+`tests/integration/vfs-performance-v5.11.1.test.ts` is intentionally skipped on
+CI for that reason), so no fixed percentage is quoted here.
+
+**Why this matters**:
+- Most `brain.get()` calls don't need vectors (VFS, admin tools, import utilities, data APIs)
+- The embedding dominates an entity's serialized size, so skipping it is the largest win
+- **Zero code changes** for most applications — automatic by default
+
+**When to use what**:
+```typescript
+// DEFAULT: Metadata-only (skips the vector load) - use for:
+const entity = await brain.get(id)
+// - VFS operations (readFile, stat, readdir)
+// - Existence checks: if (await brain.get(id)) ...
+// - Metadata access: entity.data, entity.type, entity.metadata
+// - Relationship traversal
+
+// EXPLICIT: Full entity (same as before) - use ONLY for:
+const entity = await brain.get(id, { includeVectors: true })
+// - Computing similarity on THIS entity
+// - Manual vector operations
+// - Vector index graph traversal
+```
+
+## Architecture Deep Dive
+
+### 1. Metadata Index - O(1) Lookups
+
+The `MetadataIndexManager` uses inverted indexes for lightning-fast metadata filtering.
+
+**UPDATED**: Sorted indices for range queries are now built **incrementally during CRUD operations**. No lazy loading delays - range queries are consistently fast. Binary search insertions maintain O(log n) performance during updates.
+
+```typescript
+class MetadataIndexManager {
+  // O(1) exact match via HashMap
+  private indexCache = new Map<string, MetadataIndexEntry>()
+  
+  // O(log n) range queries via sorted arrays (incremental updates)
+  private sortedIndices = new Map<string, SortedFieldIndex>()
+  
+  // Type-field affinity for intelligent NLP
+  private typeFieldAffinity = new Map<string, Map<string, number>>()
+  
+  interface MetadataIndexEntry {
+    field: string
+    value: string | number | boolean
+    ids: Set<string>  // O(1) add/remove/has
+  }
+  
+  interface SortedFieldIndex {
+    values: Array<[value: any, ids: Set<string>]>  // Sorted for O(log n) ranges
+    fieldType: 'number' | 'string' | 'date'
+  }
+}
+```
+
+**How it works:**
+1. Each field+value combination gets a unique key: `"category:tech"`
+2. Map lookup is O(1) average case
+3. Returns a Set of matching IDs instantly
+
+**Example Query:**
+```javascript
+// Query: { where: { category: 'tech' } }
+// Internally: indexCache.get('category:tech') → O(1)
+```
+
+### 2. Range Queries - O(log n)
+
+For numeric/date fields, Brainy maintains sorted indices:
+
+```typescript
+interface SortedFieldIndex {
+  values: Array<[value: any, ids: Set<string>]>  // Sorted by value
+  fieldType: 'number' | 'string' | 'date'
+}
+```
+
+**How it works:**
+1. Binary search to find range start: O(log n)
+2. Binary search to find range end: O(log n)
+3. Collect all IDs in range: O(k) where k = items in range
+
+**Example Query:**
+```javascript
+// Query: { where: { age: { greaterThan: 25, lessThan: 40 } } }
+// Internally: binarySearch(25) + binarySearch(40) + collect
+```
+
+### 3. Graph Adjacency Index - O(1) Traversal
+
+The `GraphAdjacencyIndex` provides instant graph traversal:
+
+```typescript
+class GraphAdjacencyIndex {
+  // Bidirectional adjacency lists
+  private sourceIndex = new Map<string, Set<string>>()  // id → outgoing
+  private targetIndex = new Map<string, Set<string>>()  // id → incoming
+  
+  // O(1) neighbor lookup
+  async getNeighbors(id: string, direction: 'in' | 'out' | 'both') {
+    const outgoing = this.sourceIndex.get(id)  // O(1)
+    const incoming = this.targetIndex.get(id)  // O(1)
+  }
+}
+```
+
+**Key Innovation:** Pure Map/Set operations - no database queries, no loops, just direct memory access.
+
+### 4. Vector Index - O(log n)
+
+The default vector index (`JsHnswVectorIndex`) provides logarithmic approximate nearest neighbor search through a hierarchical graph:
+
+```typescript
+class JsHnswVectorIndex {
+  private nouns: Map<string, HNSWNoun> = new Map()
+
+  interface HNSWNoun {
+    id: string
+    vector: number[]
+    connections: Map<number, Set<string>>  // layer → neighbors
+    level: number
+  }
+}
+```
+
+**How it works:**
+1. Start at entry point (top layer)
+2. Greedy search to find nearest neighbor at each layer
+3. Move down layers for progressively finer search
+4. Each layer has M connections (typically 16)
+
+**Performance:** O(log n) due to hierarchical structure
+
+### 5. Type-Aware NLP with Dynamic Field Discovery
+
+The NLP processor uses **zero hardcoded fields** - everything is discovered dynamically from actual data:
+
+```typescript
+class NaturalLanguageProcessor {
+  // Pre-embedded NounTypes (42) and VerbTypes (127) - ONLY hardcoded vocabularies
+  private nounTypeEmbeddings = new Map<string, Vector>()
+  private verbTypeEmbeddings = new Map<string, Vector>()
+  
+  // Dynamic field embeddings from actual indexed data
+  private fieldEmbeddings = new Map<string, Vector>()
+  
+  // Type-field affinity for intelligent prioritization
+  async getFieldsForType(nounType: NounType) {
+    return this.brain.getFieldsForType(nounType)  // Real data patterns
+  }
+}
+```
+
+**Type-Aware Intelligence Flow:**
+1. **Type Detection**: "documents" → `NounType.Document` (semantic similarity)
+2. **Field Prioritization**: Get fields common to Document type from real data
+3. **Semantic Field Matching**: "by" → "author" (with type affinity boost)
+4. **Validation**: Ensure "author" field actually appears with Document entities
+5. **Query Optimization**: Process low-cardinality type-specific fields first
+
+**Performance Characteristics:**
+- Type detection: O(t) where t = 169 total types (42 noun + 127 verb)
+- Field matching: O(f) where f = fields for detected type (typically 5-15)
+- Validation: O(1) lookup in type-field affinity map
+- No hardcoded assumptions - learns from actual data patterns
+
+### 6. NLP with 220 Pre-computed Patterns
+
+Pattern matching with embedded templates for instant semantic understanding:
+
+```typescript
+// 394KB of embedded patterns compiled into the source
+export const EMBEDDED_PATTERNS: Pattern[] = [/* 220 patterns */]
+export const PATTERN_EMBEDDINGS: Float32Array = /* 220 × 384 dimensions */
+```
+
+**How it works:**
+1. Query embedding computed once: O(1) with cached model
+2. Cosine similarity with 220 patterns: O(m) where m = 220
+3. Pattern templates enhanced with type context
+4. No network calls, no external dependencies, no hardcoded fields
+
+## Parallel Execution
+
+Triple Intelligence queries execute searches in parallel:
+
+```javascript
+// Vector and proximity searches run simultaneously
+const searchPromises = [
+  this.executeVectorSearch(params),    // Runs in parallel
+  this.executeProximitySearch(params)  // Runs in parallel
+]
+const results = await Promise.all(searchPromises)
+```
+
+## Memory Efficiency
+
+### Space Complexity
+
+| Component | Memory Usage | Formula |
+|-----------|--------------|---------|
+| Metadata Index | ~40 bytes/entry | `(key_size + 8) × unique_values + 8 × total_items` |
+| Graph Index | ~24 bytes/edge | `16 × edges + 8 × nodes` |
+| Vector Index | ~1.5KB/item | `vector_size × 4 + M × 8 × layers` |
+| Pattern Library | 394KB fixed | Pre-computed, shared across instances |
+| Type Embeddings | ~60KB fixed | 70 types × 384 dimensions × 4 bytes, cached |
+| Field Embeddings | ~5KB dynamic | Actual fields × 384 dimensions × 4 bytes |
+| Type-Field Affinity | ~2KB dynamic | Type-field occurrence counts |
+
+### Caching Strategy
+
+- **Metadata Cache**: LRU with 5-minute TTL, 500 entries max
+- **Embedding Cache**: Permanent for session, prevents recomputation
+- **Unified Cache**: Coordinates memory across all components
+
+## Benchmarks
+
+### Illustrative Single Run (100 items, one machine)
+
+Example output from a single 100-item run — illustrative only, not a committed
+benchmark; absolute numbers vary by hardware. The values feed the
+[Core Performance Summary](#core-performance-summary) example-latency column.
+
+```
+Metadata exact match: 0.818ms (50 items matched)
+Metadata range query: 0.631ms (40 items in range)
+Graph neighbor lookup: 0.092ms (2 connections)
+Vector k-NN search:    1.773ms (10 nearest neighbors)
+NLP query parsing:     8.906ms (full natural language)
+Triple Intelligence:   1.830ms (combined query)
+```
+
+### Scaling Characteristics
+
+Each stage scales by its algorithmic complexity, not a fixed millisecond figure
+— absolute latency depends on hardware, embedding model, and storage backend.
+Only the graph adjacency index carries a committed scale assertion:
+
+| Query stage | Complexity | Scaling behavior |
+|-------------|------------|------------------|
+| Metadata filter (exact) | O(1) | Constant — independent of dataset size |
+| Metadata filter (range) | O(log n) + O(k) | Sub-linear; k = matching results |
+| Vector search (HNSW) | O(log n) | Degrades gracefully via hierarchical layers |
+| Graph hop | O(1) | Measured <1 ms per neighbor lookup, validated up to 1M relationships (`tests/performance/graph-scale-performance.test.ts:238`) |
+| Combined query | O(log n) | Bounded by the vector stage; metadata and graph stages stay O(1)/O(log n) |
+
+## Comparison with Other Systems
+
+| System | Metadata Filter | Graph Traversal | Vector Search | Natural Language |
+|--------|-----------------|-----------------|---------------|------------------|
+| **Brainy** | O(1) HashMap | O(1) Adjacency | O(log n) vector index | 220 patterns |
+| Neo4j | O(log n) B-tree | O(k) traversal | Not native | Not native |
+| Elasticsearch | O(log n) inverted | Not native | O(n) brute force* | Basic tokenization |
+| PostgreSQL | O(log n) B-tree | O(k) recursive | O(n) brute force* | Full-text only |
+| Pinecone | Not native | Not native | O(log n) | Not native |
+
+*Without additional plugins/extensions
+
+## Key Innovations
+
+1. **True O(1) Metadata Filtering**: Most databases use B-trees (O(log n)). Brainy uses HashMaps for constant-time lookups.
+
+2. **O(1) Graph Traversal**: Unlike traditional graph databases that traverse edges, Brainy maintains bidirectional adjacency maps for instant neighbor access.
+
+3. **Unified Triple Intelligence**: First system to natively combine O(1) metadata, O(1) graph, and O(log n) vector search in a single query.
+
+4. **Embedded NLP**: 220 research-based patterns with pre-computed embeddings compiled directly into the codebase - no external dependencies.
+
+5. **Parallel Search Execution**: Vector, metadata, and graph searches execute simultaneously, not sequentially.
+
+## Production Readiness
+
+- ✅ **No External Dependencies**: All algorithms implemented in pure TypeScript
+- ✅ **No Network Calls**: Everything runs locally, including embeddings
+- ✅ **Thread-Safe**: Immutable data structures where possible
+- ✅ **Memory Bounded**: Configurable cache sizes and automatic cleanup
+- ✅ **Single-Node by Design**: One process owns one `path`; scale out at the service layer
+- ✅ **Zero Stubs**: Every line of code is production-ready
+
+## Lazy Loading Performance
+
+Brainy supports two initialization modes for optimal performance across different use cases:
+
+### Mode 1: Auto-Rebuild (Default)
+
+```javascript
+const brain = new Brainy()
+await brain.init()  // Rebuilds indexes during init (~500ms-3s for 10K entities)
+```
+
+**Performance:**
+- Init time: 500ms-3s (depends on dataset size)
+- First query: Instant (indexes already loaded)
+- Use case: Traditional applications, long-running servers
+
+### Mode 2: Lazy Loading
+
+```javascript
+const brain = new Brainy({ disableAutoRebuild: true })
+await brain.init()  // Returns instantly (0-10ms)
+
+const results = await brain.find({ limit: 10 })  // First query triggers rebuild (~50-200ms)
+const more = await brain.find({ limit: 100 })    // Subsequent queries instant (0ms check)
+```
+
+**Performance:**
+- Init time: 0-10ms (instant)
+- First query: 50-200ms (includes index rebuild for 1K-10K entities)
+- Subsequent queries: 0ms check (instant)
+- Concurrent queries: Wait for same rebuild (mutex prevents duplicates)
+
+**Concurrency Safety:**
+```javascript
+// 100 concurrent queries immediately after init
+await brain.init()
+
+const promises = Array.from({ length: 100 }, () =>
+  brain.find({ limit: 10 })
+)
+
+const results = await Promise.all(promises)
+// ✅ Only 1 rebuild triggered (mutex)
+// ✅ All 100 queries return correct results
+// ✅ Total time: ~60ms (not 6000ms!)
+```
+
+**Use Cases for Lazy Loading:**
+- **Serverless/Edge**: Minimize cold start time (0-10ms init)
+- **Development**: Faster restarts during development
+- **Large datasets**: Defer index loading until needed
+- **Read-heavy workloads**: Writes don't wait for index rebuild
+
+## Zero Configuration Required
+
+Brainy is designed to be **smart enough to tune itself dynamically**. No configuration needed:
+
+```javascript
+// That's it. Brainy handles everything.
+const brain = new Brainy()
+await brain.init()
+
+// Or with lazy loading for serverless
+const brain = new Brainy({ disableAutoRebuild: true })
+await brain.init()  // Instant (0-10ms)
+```
+
+### Automatic Self-Tuning
+
+- **Metadata Index**: Auto-builds sorted indices for range queries on first use
+- **Graph Index**: Auto-flushes every 30 seconds
+- **Default Tuning**: Research-based vector index defaults
+- **Lazy Loading**: Indices built only when needed
+- **Cache Management**: LRU caches with TTL
+
+### Intelligent Defaults
+
+- **Vector recall** = `'balanced'` (M=16, ef=200): right for most datasets
+- **Cache TTL** = 5 min: balances freshness and performance
+- **Flush interval** = 30 s: non-blocking background persistence
+
+### Vector Index Tuning Knobs
+
+Brainy 8.0 exposes two knobs on `config.vector`:
+
+```javascript
+const brain = new Brainy({
+  vector: {
+    recall: 'fast',                // 'fast' | 'balanced' | 'accurate'
+    persistMode: 'deferred'        // 'immediate' | 'deferred'
+  }
+})
+```
+
+The default JS index is `JsHnswVectorIndex`. An optional native acceleration package (`@soulcraft/cor`) can replace it with a higher-performing implementation; the public knobs stay the same.
+
+### Scale Scenarios
+
+| Scale | Items | Storage Strategy | Performance |
+|-------|-------|------------------|-------------|
+| **Small** | <10K | Memory | Sub-millisecond |
+| **Medium** | 10K-1M | Filesystem | 1-5ms |
+| **Large** | 1M-10M | Filesystem + tuned cache | 2-10ms |
+| **Massive** | 10M+ | Filesystem + native vector provider + service-layer sharding | 5-20ms |
+
+For >10M entities, run multiple Brainy processes behind your own routing layer — Brainy 8.0 doesn't ship cluster coordination.
+
+### Architecture
+
+```
+┌─────────────────────────────────────────┐
+│         Application Layer               │
+│         (Your Code)                     │
+└─────────────┬───────────────────────────┘
+              │
+┌─────────────▼───────────────────────────┐
+│         Brainy Core                     │
+│   (Triple Intelligence Engine)          │
+├─────────────────────────────────────────┤
+│  Memory     │  Vector     │  Metadata   │
+│  Cache      │  Index      │  Index      │
+└─────────────┬───────────────────────────┘
+              │
+┌─────────────▼───────────────────────────┐
+│         Storage Layer                   │
+├──────────┬──────────┬──────────────────┤
+│ Vectors  │  Graph   │   Files          │
+│ (sharded)│  Edges   │  (filesystem)    │
+└──────────┴──────────┴──────────────────┘
+```
+
+For off-site replication, snapshot `path` from your scheduler (`gsutil rsync`, `aws s3 sync`, `rclone`, or `tar`).
+
+### Performance at Scale
+
+- **Metadata queries**: O(1) HashMap
+- **Graph traversal**: O(1) adjacency lookup
+- **Vector search**: O(log n)
+- **Write throughput**: 50K+ writes/second per process (filesystem, batched)
+- **Read throughput**: 1M+ reads/second with caching
+
+### Zero-Config with Autoscaling
+
+- **AutoConfiguration System**: Detects environment and adjusts settings
+- **Learning from Performance**: `learnFromPerformance()` adapts based on metrics
+- **Auto-flush**: Graph index (30s), Metadata index (configurable)
+- **Auto-optimize**: Enabled by default in graph and vector indices
+- **Zero-config presets**: Production, development, minimal modes
+- **Adaptive memory**: Scales caches based on available memory
+
+## Implementation Status
+
+### Fully Implemented and Production-Ready
+- **O(1) metadata lookups** via HashMaps (exact match)
+- **O(log n) range queries** via sorted arrays with lazy building
+- **O(1) graph traversal** via adjacency maps
+- **O(log n) vector search** via the default JS index, swappable for a native provider
+- **220 NLP patterns** with pre-computed embeddings
+- **Filesystem and memory storage** adapters
+- **Auto-configuration system** with environment detection
+- **Zero-config operation** with intelligent defaults
+- **Auto-flush and auto-optimize** in indices
+- **Low-latency Triple Intelligence queries** (O(log n) vector + O(1) metadata/graph)
+
+## Conclusion
+
+Brainy delivers on its promise of **production-ready Triple Intelligence** with documented algorithmic-complexity guarantees and a committed graph-scale benchmark (`tests/performance/graph-scale-performance.test.ts`). All listed features are fully implemented and tested. No stubs, no mocks — just real, working code with characterized performance.

docs/PLUGINS.md

@@ -0,0 +1,486 @@
+---
+title: Plugin System
+slug: guides/plugins
+public: true
+category: guides
+template: guide
+order: 4
+description: Replace any Brainy subsystem — distance functions, embeddings, vector index, metadata index, aggregation — with a custom implementation or optional native acceleration.
+next:
+  - guides/storage-adapters
+---
+
+# Plugin Development Guide
+
+Brainy has a plugin system that allows third-party packages to replace internal subsystems with custom implementations. This is how `@soulcraft/cor` provides optional native acceleration, and it's the same system available to any developer.
+
+## Architecture Overview
+
+Brainy's plugin system uses **named providers** — string keys mapped to implementations. During `init()`, brainy:
+
+1. Imports each package listed in the `plugins` config array
+2. Activates each plugin, passing a `BrainyPluginContext`
+3. The plugin calls `context.registerProvider(key, implementation)` for each subsystem it provides
+4. Brainy checks each provider key and wires the implementation into its internal pipeline
+
+Installing the first-party accelerator is the opt-in: with the default config, brainy probes for `@soulcraft/cor` and loads it when present. Everything except "not installed" fails **loud** — a present-but-broken accelerator makes `init()` throw rather than silently degrading to the JS engines.
+
+```typescript
+const brain = new Brainy()                                  // @soulcraft/cor auto-detected when installed
+const pinned = new Brainy({ plugins: ['@soulcraft/cor'] })  // or pin exactly what loads
+const plain = new Brainy({ plugins: [] })                   // or opt out of detection entirely
+```
+
+| `plugins` value | Behavior |
+|---|---|
+| `undefined` (default) | Guarded auto-detection of `@soulcraft/cor`: not installed → no plugins, silently; installed → loads + announces; installed-but-broken → `init()` throws |
+| `false` / `[]` | No plugins, no detection (explicit opt-out) |
+| `['@soulcraft/cor']` | Load only the listed packages; a listed plugin that fails to load throws |
+
+Plugins registered programmatically via `brain.use(plugin)` are always activated regardless of the `plugins` config.
+
+If no plugin provides a given key, brainy uses its built-in JavaScript implementation. This means brainy works perfectly standalone — plugins only enhance performance or add capabilities.
+
+## Creating a Plugin
+
+### 1. Implement the `BrainyPlugin` interface
+
+```typescript
+import type { BrainyPlugin, BrainyPluginContext } from '@soulcraft/brainy/plugin'
+
+const myPlugin: BrainyPlugin = {
+  name: 'my-brainy-plugin',  // Must be unique (typically your npm package name)
+
+  async activate(context: BrainyPluginContext): Promise<boolean> {
+    // Register your providers here
+    context.registerProvider('distance', myFastDistanceFunction)
+
+    // Return true if activation succeeded, false to skip
+    return true
+  },
+
+  async deactivate(): Promise<void> {
+    // Optional cleanup when brainy.close() is called
+  }
+}
+
+export default myPlugin
+```
+
+### 2. Package exports
+
+Your package must export the plugin as the default export so brainy's plugin loader can resolve it:
+
+```typescript
+// index.ts
+export { default } from './plugin.js'
+```
+
+### 3. Registration
+
+**Config-based:** List your package name in the brainy config:
+
+```typescript
+const brain = new Brainy({
+  plugins: ['my-brainy-plugin']
+})
+await brain.init()
+```
+
+**Programmatic registration:** For plugins not installed as npm packages, use `brain.use()`:
+
+```typescript
+import { Brainy } from '@soulcraft/brainy'
+import myPlugin from './my-plugin.js'
+
+const brain = new Brainy()
+brain.use(myPlugin)
+await brain.init()
+```
+
+## Provider Keys Reference
+
+Each key has a specific expected signature. Brainy checks for these during `init()` and wires them into the appropriate code paths.
+
+### Core Providers
+
+#### `distance`
+**Type:** `(a: number[], b: number[]) => number`
+
+Replaces the default cosine distance function used in vector search and neural APIs. This is the highest-impact single provider — it's called for every vector comparison.
+
+```typescript
+context.registerProvider('distance', (a: number[], b: number[]): number => {
+  // Your SIMD-accelerated or GPU distance calculation
+  return myFastCosineDistance(a, b)
+})
+```
+
+#### `embeddings`
+**Type:** `(text: string | string[]) => Promise<number[] | number[][]>`
+
+Replaces the built-in WASM embedding engine. Called for every `brain.add()`, `brain.update()`, and `brain.find()` operation that involves text.
+
+```typescript
+context.registerProvider('embeddings', async (text: string | string[]) => {
+  if (Array.isArray(text)) {
+    return myEngine.embedBatch(text)
+  }
+  return myEngine.embed(text)
+})
+```
+
+#### `embedBatch`
+**Type:** `(texts: string[]) => Promise<number[][]>`
+
+Dedicated batch embedding provider. When registered, brainy uses this for bulk operations (import, reindex, batch add) instead of calling the `embeddings` provider N times. This enables true single-forward-pass batch processing.
+
+Priority order for batch operations:
+1. `embedBatch` provider (single forward pass — fastest)
+2. `embeddings` provider with `Promise.all()` (N individual calls)
+3. Built-in WASM batch API (fallback)
+
+```typescript
+context.registerProvider('embedBatch', async (texts: string[]) => {
+  // Process all texts in a single forward pass
+  return myEngine.batchEmbed(texts)
+})
+```
+
+### Index Providers
+
+> **Write-path invariant (the change-feed contract).** Every canonical
+> mutation flows through Brainy's generation-store commit points — index
+> providers are invoked *inside* that commit and never originate canonical
+> writes of their own. The `brain.onChange` change feed is emitted from those
+> commit points and relies on this: **a plugin must never introduce a write
+> path that bypasses the generation-store commit.** If a future provider ever
+> needs a direct native ingest path, it must either route through the commit
+> or emit equivalent change events — otherwise every `onChange` consumer
+> (live UIs, cache invalidation, realtime sync) silently develops a blind
+> spot.
+
+#### `vector`
+**Type:** `(config: object, distanceFunction: Function, options: object) => VectorIndexProvider-compatible`
+
+Factory function that creates a vector index instance. The returned object must implement the `VectorIndexProvider` public API:
+
+- `addItem(item: { id: string, vector: number[] }): Promise<string>`
+- `search(queryVector: number[], k: number, filter?, options?): Promise<Array<[string, number]>>`
+- `removeItem(id: string): Promise<boolean>`
+- `size(): number`
+- `clear(): void`
+- `flush(): Promise<number>`
+- `rebuild(options?): Promise<void>`
+- `getDirtyNodeCount(): number`
+- `getPersistMode(): 'immediate' | 'deferred'`
+- `getEntryPointId(): string | null`
+- `getMaxLevel(): number`
+- `getDimension(): number | null`
+- `getConfig(): object`
+- `getDistanceFunction(): Function`
+- `enableCOW(parent): void`
+- `setUseParallelization(boolean): void`
+
+For type-aware indexes (separate graph per noun type), also implement:
+- `getIndexForType(type: string): VectorIndexProvider` (duck-typed detection)
+- `search(queryVector, k, type?, filter?, options?): Promise<Array<[string, number]>>`
+
+```typescript
+context.registerProvider('vector', (config, distanceFn, options) => {
+  return new MyNativeVectorIndex(config, distanceFn, options)
+})
+```
+
+#### The readiness contract (all three index providers)
+
+A provider that **persists its derived index** should implement the optional readiness
+members so a warm reopen never pays a redundant rebuild-from-canonical:
+
+- **`init?(): Promise<void>`** — eager cold-load. Brainy awaits it once during
+  `brain.init()`, after the metadata provider's `init()` (the id-mapper hydrates first)
+  and **before the rebuild gate**.
+- **`isReady?(): boolean`** — honest durability signal. `true` ⇔ the persisted index is
+  loaded (or cheaply demand-loadable) and consistent with what was last persisted. When
+  exposed, the rebuild gate defers to this signal **instead of** the `size() === 0` /
+  `totalEntries === 0` heuristics — a disk-native index may report 0 resident entries
+  while fully durable. Never return `true` if the durable state failed to load: the
+  signal is honest in both directions, and a not-ready provider gets its rebuild even
+  when `size() > 0`.
+- **`isMigrating?(): boolean`** — while `true`, the provider owns its index (background
+  migration); brainy skips its rebuild entirely.
+
+Providers that implement none of these keep the size/count heuristics — correct for
+engines whose `rebuild()` *is* their load path (like brainy's built-in JS vector index).
+
+#### `metadataIndex`
+**Type:** `(storage: StorageAdapter) => MetadataIndexManager-compatible`
+
+Factory function that creates a metadata index. The returned object must implement the `MetadataIndexManager` interface including `init()`, `addEntity()`, `removeEntity()`, `query()`, `flush()`, `clear()`, etc.
+
+```typescript
+context.registerProvider('metadataIndex', (storage) => {
+  return new MyNativeMetadataIndex(storage)
+})
+```
+
+#### `graphIndex`
+**Type:** `(storage: StorageAdapter) => GraphAdjacencyIndex-compatible`
+
+Factory function that creates a graph adjacency index for relationship tracking (verbs/triples). Must implement the `GraphAdjacencyIndex` interface including `addVerb()`, `getVerbsBySource()`, `getVerbsByTarget()`, `flush()`, etc.
+
+```typescript
+context.registerProvider('graphIndex', (storage) => {
+  return new MyNativeGraphIndex(storage)
+})
+```
+
+#### `aggregation`
+**Type:** `(storage: StorageAdapter) => AggregationProvider-compatible`
+
+Factory function that creates an aggregation engine for write-time incremental SUM/COUNT/AVG/MIN/MAX with GROUP BY and time windows. The returned object must implement the `AggregationProvider` interface.
+
+```typescript
+context.registerProvider('aggregation', (storage) => {
+  return new MyNativeAggregationEngine(storage)
+})
+```
+
+When provided by an optional native acceleration plugin (such as `@soulcraft/cor`), this enables:
+- Compiled source filters (vs per-entity JS object traversal)
+- Precise MIN/MAX via sorted data structures (vs lazy recompute)
+- Parallel aggregate rebuild across CPU cores
+- SIMD-accelerated timestamp bucketing
+
+### Utility Providers
+
+#### `cache`
+**Type:** `UnifiedCache`
+
+Replaces the global `UnifiedCache` singleton used for VFS path resolution, semantic caching, and vector index caching. Must implement the `UnifiedCache` interface (available from `@soulcraft/brainy/internals`).
+
+```typescript
+import type { UnifiedCache } from '@soulcraft/brainy/internals'
+
+context.registerProvider('cache', myNativeCache)
+```
+
+#### `entityIdMapper`
+**Type:** `(storage: StorageAdapter) => EntityIdMapper-compatible`
+
+Factory for bidirectional UUID ↔ integer mapping used by roaring bitmaps. Must implement `getOrAssign()`, `getUuid()`, `getInt()`, `has()`, `remove()`, `flush()`, `clear()`.
+
+#### `roaring`
+**Type:** `RoaringBitmap32 class`
+
+Replacement for the roaring bitmap implementation. Used internally by the metadata index for set operations. Must be API-compatible with `roaring-wasm`.
+
+#### `msgpack`
+**Type:** `{ encode: (data: any) => Buffer, decode: (buffer: Buffer) => any }`
+
+Native msgpack encode/decode for SSTable serialization.
+
+### Analytics Providers (Native-Only)
+
+These provider keys have **no JavaScript fallback** — they represent capabilities that require native code (SIMD, mmap, sub-microsecond latency). They are available when an optional native acceleration plugin (such as `@soulcraft/cor`) is installed.
+
+Use `brain.getProvider('analytics:hyperloglog')` to check availability. Returns `undefined` if no plugin provides it.
+
+#### `analytics:hyperloglog`
+Approximate distinct counts. Count unique values (e.g., unique merchants) across millions of records using ~16KB of memory with ~1% error. Each update is O(1).
+
+#### `analytics:tdigest`
+Streaming percentiles. Compute P50/P90/P95/P99 from streaming data without storing all values. Uses ~4KB per digest with ~1% accuracy at the tails.
+
+#### `analytics:countmin`
+Frequency estimation. Find the most common values (e.g., top-K merchants) using ~40KB with 0.1% error. O(1) per update.
+
+#### `analytics:anomaly`
+Real-time anomaly detection. Flag statistically unusual values at write-time using exponentially weighted moving averages. 64 bytes per group, sub-microsecond decisions.
+
+#### `aggregation:mmap`
+Persistent aggregate storage via memory-mapped files. Aggregate state survives process crashes without explicit flush. Zero serialization overhead.
+
+---
+
+## Storage Adapter Plugins
+
+Plugins can register custom storage backends that users reference by name.
+
+### Implementing a Storage Adapter
+
+```typescript
+import type { StorageAdapterFactory } from '@soulcraft/brainy/plugin'
+import type { StorageAdapter } from '@soulcraft/brainy'
+
+class MyStorageAdapter implements StorageAdapter {
+  async init(): Promise<void> { /* ... */ }
+  async saveNoun(noun: HNSWNoun): Promise<void> { /* ... */ }
+  async getNoun(id: string): Promise<HNSWNounWithMetadata | null> { /* ... */ }
+  async deleteNoun(id: string): Promise<void> { /* ... */ }
+  // ... implement all StorageAdapter methods
+}
+```
+
+### Registering a Storage Adapter
+
+```typescript
+context.registerProvider('storage:my-backend', {
+  name: 'my-backend',
+  create: (config: Record<string, unknown>) => {
+    return new MyStorageAdapter(config)
+  }
+} satisfies StorageAdapterFactory)
+```
+
+Users can then use your storage:
+
+```typescript
+const brain = new Brainy({ storage: 'my-backend', myBackendOption: 'value' })
+```
+
+## Import Paths
+
+Brainy provides three entry points for plugin developers:
+
+| Import Path | Contents | Stability |
+|-------------|----------|-----------|
+| `@soulcraft/brainy` | Public API, types, StorageAdapter | Stable (semver) |
+| `@soulcraft/brainy/plugin` | BrainyPlugin, BrainyPluginContext, StorageAdapterFactory | Stable (semver) |
+| `@soulcraft/brainy/internals` | UnifiedCache, EntityIdMapper, logger utilities | Internal (may change between minor versions) |
+
+## Diagnostics
+
+Brainy provides a `diagnostics()` method to verify plugin wiring:
+
+```typescript
+const brain = new Brainy()
+await brain.init()
+
+const diag = brain.diagnostics()
+console.log(diag)
+// {
+//   version: '7.14.0',
+//   plugins: { active: ['my-plugin'], count: 1 },
+//   providers: {
+//     metadataIndex: { source: 'default' },
+//     graphIndex: { source: 'default' },
+//     embeddings: { source: 'plugin' },
+//     embedBatch: { source: 'plugin' },
+//     distance: { source: 'plugin' },
+//     vector: { source: 'default' },
+//     ...
+//   },
+//   indexes: {
+//     vector: { size: 0, type: 'JsHnswVectorIndex' },
+//     metadata: { type: 'MetadataIndexManager', initialized: true },
+//     graph: { type: 'GraphAdjacencyIndex', initialized: true, wiredToStorage: true }
+//   }
+// }
+```
+
+The CLI also supports diagnostics:
+
+```bash
+brainy diagnostics
+```
+
+### Init-Time Summary
+
+When a plugin is active, brainy automatically logs a provider summary after `init()`:
+
+```
+[brainy] Plugin activated: @soulcraft/cor
+[brainy] Providers: 8/10 native (@soulcraft/cor) | default: vector, cache
+```
+
+This tells you at a glance how many subsystems are accelerated and which ones are falling back to JavaScript. The log respects `config.silent`.
+
+### Fail-Fast for Production
+
+Use `requireProviders()` after `init()` to guarantee specific providers are plugin-supplied. This prevents silent fallback to JavaScript in deployments where you expect native acceleration:
+
+```typescript
+const brain = new Brainy()
+await brain.init()
+
+// Throws immediately if any of these are using JS fallback
+brain.requireProviders(['distance', 'embeddings', 'metadataIndex', 'graphIndex'])
+```
+
+If a required provider is missing, the error message tells you exactly what's wrong:
+
+```
+[brainy] Required providers using JS fallback: graphIndex.
+Active plugins: @soulcraft/cor.
+These providers must be supplied by a plugin for this deployment.
+Check plugin installation, license, and native module availability.
+```
+
+This is the recommended pattern for production deployments with paid plugins — fail at startup rather than silently degrading performance.
+
+## Complete Example: Distance Acceleration Plugin
+
+A minimal but useful plugin that provides SIMD-accelerated distance calculations:
+
+```typescript
+// simd-distance-plugin/src/plugin.ts
+import type { BrainyPlugin, BrainyPluginContext } from '@soulcraft/brainy/plugin'
+
+// Hypothetical native module
+import { simdCosineDistance } from './native.js'
+
+const simdDistancePlugin: BrainyPlugin = {
+  name: 'brainy-simd-distance',
+
+  async activate(context: BrainyPluginContext): Promise<boolean> {
+    // Check if SIMD is available on this platform
+    if (!checkSimdSupport()) {
+      console.log('[simd-distance] SIMD not available, skipping')
+      return false  // Don't activate — brainy uses JS fallback
+    }
+
+    context.registerProvider('distance', simdCosineDistance)
+    return true
+  }
+}
+
+export default simdDistancePlugin
+```
+
+```json
+// simd-distance-plugin/package.json
+{
+  "name": "brainy-simd-distance",
+  "main": "./dist/plugin.js",
+  "types": "./dist/plugin.d.ts",
+  "peerDependencies": {
+    "@soulcraft/brainy": ">=7.0.0"
+  }
+}
+```
+
+Usage:
+
+```typescript
+import { Brainy } from '@soulcraft/brainy'
+
+const brain = new Brainy({ plugins: ['brainy-simd-distance'] })
+await brain.init()
+
+// Verify it's active
+const diag = brain.diagnostics()
+console.log(diag.providers.distance) // { source: 'plugin' }
+```
+
+## Design Principles
+
+1. **Brainy works perfectly without plugins.** Every provider has a JavaScript fallback. Plugins only improve performance or add capabilities.
+
+2. **Provider keys are string-based.** The plugin system is not coupled to any specific plugin. Any package can register any provider.
+
+3. **Clean separation.** Plugins access brainy through the documented `BrainyPluginContext` interface. No direct access to internal classes is needed.
+
+4. **Fail-safe activation.** If a plugin throws during `activate()`, brainy logs a warning and continues with defaults. A broken plugin never prevents brainy from working.
+
+5. **Lifecycle management.** `deactivate()` is called during `brainy.close()` for resource cleanup. Native resources, connections, and file handles should be released here.

docs/PRODUCTION_SERVICE_ARCHITECTURE.md

@@ -0,0 +1,562 @@
+# Production Service Architecture Guide
+
+**How to use Brainy optimally in production services (Bun, Node.js, Deno)**
+
+> **Recommended Runtime:** [Bun](https://bun.sh) provides best performance with Brainy's Candle WASM engine. All examples work with both Bun and Node.js.
+
+---
+
+## The Problem: Instance-per-Request Anti-Pattern
+
+### ❌ What NOT to Do
+
+```typescript
+// WRONG - Creates new instance EVERY request
+app.get('/api/entities', async (req, res) => {
+  const brain = new Brainy({ storage: { path: './brainy-data' } })
+  await brain.init()  // FULL INITIALIZATION EVERY TIME!
+  const entities = await brain.find(...)
+  res.json(entities)
+})
+```
+
+### Why This is Terrible
+
+After 40 API calls:
+- **40 Brainy instances** running simultaneously
+- **20GB memory** (40 × 500MB per instance)
+- **2 seconds wasted** (40 × 50ms initialization)
+- **Zero cache benefit** (each instance has its own empty cache)
+- **Index rebuilding** on every request (TypeAware HNSW, LSM-trees, etc.)
+- **Memory leaks** (old instances may not GC properly)
+
+---
+
+## ✅ The Solution: Singleton Pattern
+
+**ONE Brainy instance per service, shared across ALL requests.**
+
+### Performance Comparison
+
+| Metric | Instance-per-Request | Singleton (Optimal) |
+|--------|---------------------|---------------------|
+| Memory (40 requests) | 20GB | 500MB |
+| Request 1 latency | 60ms | 60ms (one-time init) |
+| Request 2+ latency | 60ms (no cache!) | 2ms (80% cache hit!) |
+| Cache hit rate | 0% | 80%+ |
+| Speedup | - | **30x faster** |
+
+---
+
+## Implementation Patterns
+
+### Pattern 1: Simple Singleton (Recommended)
+
+```typescript
+// server.ts
+import { Brainy } from '@soulcraft/brainy'
+
+// SINGLETON INSTANCE
+let brainInstance: Brainy | null = null
+
+async function getBrain(): Promise<Brainy> {
+  if (brainInstance) {
+    return brainInstance
+  }
+
+  console.log('🧠 Initializing Brainy singleton...')
+
+  brainInstance = new Brainy({
+    storage: {
+      path: './brainy-data',
+      autoOptimize: true
+    },
+    cache: {
+      maxSize: 1000,      // Shared across ALL requests
+      ttl: 3600000,       // 1 hour
+      enableMetrics: true
+    },
+    augmentations: {
+      include: ['cache', 'metrics', 'display', 'vfs']
+    }
+  })
+
+  await brainInstance.init()
+  console.log('✅ Brainy ready')
+
+  return brainInstance
+}
+
+// Initialize BEFORE starting server
+async function startServer() {
+  await getBrain()  // One-time initialization
+
+  app.get('/api/entities', async (req, res) => {
+    const brain = await getBrain()  // Reuses same instance!
+    const entities = await brain.find(req.query)
+    res.json(entities)
+  })
+
+  app.listen(3000)
+}
+
+startServer()
+```
+
+**Benefits:**
+- ✅ Simple to implement
+- ✅ Thread-safe (async initialization)
+- ✅ Shared cache and indexes
+- ✅ 40x memory reduction
+
+---
+
+### Pattern 2: Service Class (Production-Grade)
+
+```typescript
+// services/BrainService.ts
+export class BrainService {
+  private brain: Brainy | null = null
+  private initPromise: Promise<Brainy> | null = null
+
+  async getInstance(): Promise<Brainy> {
+    if (this.brain) return this.brain
+    if (this.initPromise) return this.initPromise
+
+    this.initPromise = this.initialize()
+    return this.initPromise
+  }
+
+  private async initialize(): Promise<Brainy> {
+    this.brain = new Brainy({
+      storage: {
+        path: process.env.BRAINY_DATA_PATH || './brainy-data'
+      },
+      cache: { maxSize: 1000, ttl: 3600000 }
+    })
+    await this.brain.init()
+    return this.brain
+  }
+
+  async shutdown(): Promise<void> {
+    if (this.brain) {
+      // Cleanup if needed
+      this.brain = null
+    }
+  }
+}
+
+// server.ts
+const brainService = new BrainService()
+
+app.get('/api/entities', async (req, res) => {
+  const brain = await brainService.getInstance()
+  const entities = await brain.find(req.query)
+  res.json(entities)
+})
+
+// Graceful shutdown
+process.on('SIGTERM', async () => {
+  await brainService.shutdown()
+  process.exit(0)
+})
+```
+
+**Benefits:**
+- ✅ Prevents race conditions (multiple simultaneous inits)
+- ✅ Testable (can inject mock)
+- ✅ Clean shutdown handling
+- ✅ Environment-configurable
+
+---
+
+### Pattern 3: Bun Server (Recommended)
+
+```typescript
+// server.ts - Clean Bun implementation
+import { Brainy } from '@soulcraft/brainy'
+
+let brain: Brainy | null = null
+
+async function getBrain(): Promise<Brainy> {
+  if (!brain) {
+    brain = new Brainy({ storage: { path: './brainy-data' } })
+    await brain.init()
+  }
+  return brain
+}
+
+// Initialize before server starts
+await getBrain()
+
+Bun.serve({
+  port: 3000,
+  async fetch(req) {
+    const url = new URL(req.url)
+
+    if (url.pathname === '/api/entities') {
+      const b = await getBrain()
+      const entities = await b.find({})
+      return Response.json(entities)
+    }
+
+    if (url.pathname === '/api/entity' && req.method === 'POST') {
+      const b = await getBrain()
+      const body = await req.json()
+      const id = await b.add(body)
+      return Response.json({ id })
+    }
+
+    return new Response('Not Found', { status: 404 })
+  }
+})
+
+console.log('Server running on http://localhost:3000')
+```
+
+**Benefits:**
+- ✅ Native Bun runtime performance
+- ✅ No framework dependencies
+- ✅ Pure WASM — no native binaries, bundler-friendly
+- ✅ Built-in TypeScript support
+
+### Pattern 4: Express/Node.js Middleware (Legacy)
+
+```typescript
+// middleware/brainy.ts
+let brainInstance: Brainy | null = null
+
+export async function initBrainy() {
+  if (!brainInstance) {
+    brainInstance = new Brainy({ storage: { path: './brainy-data' } })
+    await brainInstance.init()
+  }
+}
+
+export function brainMiddleware(req, res, next) {
+  if (!brainInstance) {
+    return res.status(500).json({ error: 'Brainy not initialized' })
+  }
+  req.brain = brainInstance  // Attach to request
+  next()
+}
+
+// Type extension
+declare global {
+  namespace Express {
+    interface Request {
+      brain: Brainy
+    }
+  }
+}
+
+// server.ts
+import { initBrainy, brainMiddleware } from './middleware/brainy'
+
+async function startServer() {
+  await initBrainy()  // Initialize first
+
+  app.use('/api', brainMiddleware)  // Apply to API routes
+
+  app.get('/api/entities', async (req, res) => {
+    const entities = await req.brain.find(req.query)  // Type-safe!
+    res.json(entities)
+  })
+
+  app.listen(3000)
+}
+```
+
+**Benefits:**
+- ✅ Clean separation of concerns
+- ✅ Type-safe (`req.brain` is typed)
+- ✅ Easy to add auth/validation
+
+---
+
+## Optimization Strategies
+
+### 1. Configure Cache for Your Workload
+
+```typescript
+const brain = new Brainy({
+  cache: {
+    maxSize: 1000,           // Number of entities to cache
+    ttl: 3600000,            // Cache lifetime (1 hour)
+    enableMetrics: true,     // Track hit rate
+    evictionPolicy: 'lru'    // Least recently used
+  }
+})
+```
+
+**Cache sizing:**
+- Small service (< 100 req/min): `maxSize: 500`
+- Medium service (< 1000 req/min): `maxSize: 1000`
+- Large service (> 1000 req/min): `maxSize: 5000`
+
+### 2. Lazy Load Augmentations
+
+```typescript
+const brain = new Brainy({
+  augmentations: {
+    // Only load what you actually use
+    include: ['cache', 'metrics', 'display', 'vfs'],
+    exclude: ['neuralImport', 'intelligentImport']  // Skip heavy features
+  }
+})
+```
+
+**Memory savings:**
+- With all augmentations: ~800MB
+- With minimal set: ~400MB
+
+### 3. Warm Up Indexes
+
+```typescript
+async function startServer() {
+  const brain = await getBrain()
+
+  // Pre-warm frequently-used indexes
+  await brain.find({ type: 'person', limit: 1 })
+  await brain.find({ type: 'organization', limit: 1 })
+
+  console.log('✅ Indexes pre-warmed')
+
+  app.listen(3000)
+}
+```
+
+**Benefit:** First requests are fast (no cold-start index building)
+
+### 4. Memory-Aware Configuration
+
+```typescript
+import os from 'os'
+
+const totalMemory = os.totalmem()
+const availableMemory = os.freemem()
+
+const brain = new Brainy({
+  cache: {
+    // Use 10% of total RAM for cache
+    maxSize: Math.floor(totalMemory * 0.1 / (1024 * 1024))
+  },
+  indexes: {
+    // Lazy load indexes if low memory
+    lazyLoad: availableMemory < totalMemory * 0.5,
+    preload: ['person', 'organization']  // Only preload common types
+  }
+})
+```
+
+---
+
+## Concurrency & Thread Safety
+
+Brainy is **designed** for concurrent access. A single instance can handle:
+
+```typescript
+// Multiple concurrent requests - all using same instance
+app.get('/api/read/:id', async (req, res) => {
+  const brain = getBrain()
+  const entity = await brain.get(req.params.id)  // Safe - no state mutation
+  res.json(entity)
+})
+
+app.post('/api/write', async (req, res) => {
+  const brain = getBrain()
+  const id = await brain.add(req.body)  // Safe - internal locking
+  res.json({ id })
+})
+```
+
+**Concurrency mechanisms:**
+- ✅ **Read operations**: Lock-free (MVCC)
+- ✅ **Write operations**: Internal write-ahead logging (WAL)
+- ✅ **Cache**: Thread-safe LRU implementation
+- ✅ **Indexes**: Concurrent reads, locked writes
+
+---
+
+## Production Checklist
+
+### Before Deploying
+
+- [ ] **Initialize Brainy on startup** (not per-request)
+- [ ] **Configure cache size** based on memory
+- [ ] **Only load needed augmentations**
+- [ ] **Warm up critical indexes**
+- [ ] **Add graceful shutdown handler**
+- [ ] **Monitor cache hit rate**
+
+### Code Review Checklist
+
+```typescript
+// ❌ BAD - Instance per request
+app.get('/api/route', async (req, res) => {
+  const brain = new Brainy(...)  // RED FLAG!
+  await brain.init()             // RED FLAG!
+})
+
+// ✅ GOOD - Singleton pattern
+app.get('/api/route', async (req, res) => {
+  const brain = await getBrain()  // Reuses instance ✓
+})
+```
+
+---
+
+## Monitoring & Metrics
+
+```typescript
+// Add metrics endpoint
+app.get('/api/metrics', (req, res) => {
+  const brain = getBrain()
+
+  res.json({
+    cache: {
+      size: brain.cache?.size || 0,
+      maxSize: brain.cache?.maxSize || 0,
+      hitRate: brain.metrics?.cacheHitRate || 0  // Target: >70%
+    },
+    storage: brain.storage.getStats(),
+    memory: {
+      heapUsed: Math.round(process.memoryUsage().heapUsed / 1024 / 1024),
+      heapTotal: Math.round(process.memoryUsage().heapTotal / 1024 / 1024)
+    }
+  })
+})
+```
+
+**Key metrics to track:**
+- **Cache hit rate**: Should be >70% after warm-up
+- **Memory usage**: Should stay constant (~500MB for singleton)
+- **Request latency**: Should be <10ms for cached entities
+
+---
+
+## Common Pitfalls
+
+### 1. Creating instances in routes
+```typescript
+// ❌ NEVER do this
+app.get('/api/entities', async (req, res) => {
+  const brain = new Brainy(...)  // Creates new instance every time!
+})
+```
+
+### 2. Not awaiting initialization
+```typescript
+// ❌ Race condition - server starts before Brainy ready
+app.listen(3000)
+getBrain()  // Async init happens AFTER server starts!
+
+// ✅ Correct - wait for init
+await getBrain()
+app.listen(3000)
+```
+
+### 3. Multiple instances for different purposes
+```typescript
+// ❌ Wasteful - creates 2 instances
+const readBrain = new Brainy(...)
+const writeBrain = new Brainy(...)
+
+// ✅ One instance handles both
+const brain = new Brainy(...)
+await brain.get(id)    // Read
+await brain.add(data)  // Write
+```
+
+---
+
+## Migration Guide
+
+### Current (Anti-Pattern)
+```typescript
+// Probably in multiple route files
+async function handler(req, res) {
+  const brain = new Brainy({ storage: { path: './brainy-data' } })
+  await brain.init()
+  // ... use brain
+}
+```
+
+### Step 1: Create Singleton Module
+```typescript
+// lib/brainy.ts
+let instance: Brainy | null = null
+
+export async function getBrain(): Promise<Brainy> {
+  if (!instance) {
+    instance = new Brainy({ storage: { path: './brainy-data' } })
+    await instance.init()
+  }
+  return instance
+}
+```
+
+### Step 2: Update Server Startup
+```typescript
+// server.ts
+import { getBrain } from './lib/brainy'
+
+async function startServer() {
+  // Initialize Brainy FIRST
+  await getBrain()
+  console.log('✅ Brainy initialized')
+
+  // THEN start server
+  app.listen(3000)
+}
+```
+
+### Step 3: Update All Routes
+```typescript
+// Before
+async function handler(req, res) {
+  const brain = new Brainy(...)  // Remove this
+  await brain.init()              // Remove this
+
+  // ... rest of code
+}
+
+// After
+import { getBrain } from './lib/brainy'
+
+async function handler(req, res) {
+  const brain = await getBrain()  // Add this
+
+  // ... rest of code stays same
+}
+```
+
+**Expected results:**
+- ✅ 40x memory reduction (20GB → 500MB)
+- ✅ 30x faster requests (60ms → 2ms average)
+- ✅ 80%+ cache hit rate
+- ✅ Your service can scale to 1000s of requests/minute
+
+---
+
+## Summary
+
+**DO:**
+- ✅ Initialize Brainy ONCE on server startup
+- ✅ Share single instance across all requests
+- ✅ Configure cache for your workload
+- ✅ Monitor cache hit rate
+- ✅ Handle graceful shutdown
+
+**DON'T:**
+- ❌ Create new Brainy instance per request
+- ❌ Create multiple instances
+- ❌ Start server before Brainy is initialized
+- ❌ Load augmentations you don't use
+
+**Result:** 40x less memory, 30x faster requests, Brainy optimizations actually work!
+
+---
+
+**Questions? Issues?**
+- Report issues: https://github.com/soulcraftlabs/brainy/issues

docs/QUERY_OPERATORS.md

@@ -0,0 +1,298 @@
+# Query Operators (BFO)
+
+> Brainy Field Operators — the complete reference for `where` filters in `find()`.
+
+All operators work with `find({ where: { ... } })` and filter on **metadata fields** (not `data`).
+
+---
+
+## Equality
+
+| Operator | Alias | Description | Example |
+|----------|-------|-------------|---------|
+| `eq` | `equals` | Exact match | `{ status: { eq: 'active' } }` |
+| `ne` | `notEquals` | Not equal | `{ status: { ne: 'deleted' } }` |
+
+**Shorthand:** A bare value is treated as `equals`:
+
+```typescript
+// These are equivalent:
+brain.find({ where: { status: 'active' } })
+brain.find({ where: { status: { equals: 'active' } } })
+```
+
+---
+
+## Comparison
+
+| Operator | Alias | Description | Example |
+|----------|-------|-------------|---------|
+| `gt` | `greaterThan` | Greater than | `{ age: { gt: 18 } }` |
+| `gte` | `greaterThanOrEqual` | Greater or equal | `{ score: { gte: 90 } }` |
+| `lt` | `lessThan` | Less than | `{ price: { lt: 100 } }` |
+| `lte` | `lessThanOrEqual` | Less or equal | `{ rating: { lte: 3 } }` |
+| `between` | — | Inclusive range `[min, max]` | `{ year: { between: [2020, 2025] } }` |
+
+```typescript
+// Range query
+const recent = await brain.find({
+  where: {
+    createdAt: { between: [Date.now() - 86400000, Date.now()] }
+  }
+})
+```
+
+---
+
+## Array / Set
+
+| Operator | Alias | Description | Example |
+|----------|-------|-------------|---------|
+| `oneOf` | `in` | Value is one of the given options | `{ color: { oneOf: ['red', 'blue'] } }` |
+| `noneOf` | — | Value is NOT one of the given options | `{ status: { noneOf: ['deleted', 'archived'] } }` |
+| `contains` | — | Array field contains value | `{ tags: { contains: 'ai' } }` |
+| `excludes` | — | Array field does NOT contain value | `{ tags: { excludes: 'spam' } }` |
+| `hasAll` | — | Array field contains ALL listed values | `{ skills: { hasAll: ['js', 'ts'] } }` |
+
+```typescript
+// Find entities tagged with 'ai'
+const aiEntities = await brain.find({
+  where: { tags: { contains: 'ai' } }
+})
+
+// Find entities of specific types
+const people = await brain.find({
+  where: { noun: { oneOf: ['Person', 'Agent'] } }
+})
+```
+
+---
+
+## Existence
+
+| Operator | Description | Example |
+|----------|-------------|---------|
+| `exists: true` | Field exists (has any value) | `{ email: { exists: true } }` |
+| `exists: false` | Field does NOT exist | `{ email: { exists: false } }` |
+| `missing: true` | Field does NOT exist (alias for `exists: false`) | `{ email: { missing: true } }` |
+| `missing: false` | Field exists (alias for `exists: true`) | `{ email: { missing: false } }` |
+
+```typescript
+// Find entities that have an email field
+const withEmail = await brain.find({
+  where: { email: { exists: true } }
+})
+```
+
+---
+
+## Pattern (In-Memory Only)
+
+These operators work via the in-memory filter path. They are applied **after** the indexed query, so use them with other indexed operators for best performance.
+
+| Operator | Description | Example |
+|----------|-------------|---------|
+| `matches` | Regex or string pattern match | `{ name: { matches: /^Dr\./ } }` |
+| `startsWith` | String prefix | `{ name: { startsWith: 'John' } }` |
+| `endsWith` | String suffix | `{ email: { endsWith: '@gmail.com' } }` |
+
+```typescript
+const doctors = await brain.find({
+  where: {
+    type: NounType.Person,           // Indexed — fast
+    name: { startsWith: 'Dr.' }     // In-memory — applied after
+  }
+})
+```
+
+---
+
+## Logical
+
+Combine multiple conditions:
+
+| Operator | Description | Example |
+|----------|-------------|---------|
+| `allOf` | ALL sub-filters must match (AND) | `{ allOf: [{ status: 'active' }, { role: 'admin' }] }` |
+| `anyOf` | ANY sub-filter must match (OR) | `{ anyOf: [{ role: 'admin' }, { role: 'owner' }] }` |
+| `not` | Invert a filter | `{ not: { status: 'deleted' } }` |
+
+```typescript
+// Complex OR query
+const adminsOrOwners = await brain.find({
+  where: {
+    anyOf: [
+      { role: 'admin' },
+      { role: 'owner' }
+    ]
+  }
+})
+
+// NOT query
+const notDeleted = await brain.find({
+  where: {
+    not: { status: 'deleted' }
+  }
+})
+
+// Combined AND + OR
+const results = await brain.find({
+  where: {
+    allOf: [
+      { department: 'engineering' },
+      { anyOf: [
+        { level: 'senior' },
+        { yearsExperience: { greaterThan: 5 } }
+      ]}
+    ]
+  }
+})
+```
+
+---
+
+## Indexed vs In-Memory Operators
+
+Brainy's MetadataIndex supports a subset of operators natively for O(1) field lookups. Other operators fall back to in-memory filtering.
+
+| Operator | MetadataIndex (Indexed) | In-Memory Fallback |
+|----------|:-----------------------:|:------------------:|
+| `equals` / `eq` | Yes | Yes |
+| `notEquals` / `ne` | — | Yes |
+| `greaterThan` / `gt` | Yes | Yes |
+| `greaterThanOrEqual` / `gte` | Yes | Yes |
+| `lessThan` / `lt` | Yes | Yes |
+| `lessThanOrEqual` / `lte` | Yes | Yes |
+| `between` | Yes | Yes |
+| `oneOf` / `in` | Yes | Yes |
+| `noneOf` | — | Yes |
+| `contains` | Yes | Yes |
+| `exists` / `missing` | Yes | Yes |
+| `matches` | — | Yes |
+| `startsWith` | — | Yes |
+| `endsWith` | — | Yes |
+| `allOf` | Partial | Yes |
+| `anyOf` | Partial | Yes |
+| `not` | — | Yes |
+
+**Performance tip:** Combine indexed operators (equals, greaterThan, oneOf, between, contains, exists) with pattern operators for optimal speed — the index narrows results first, then patterns filter in memory.
+
+---
+
+## Practical Examples
+
+### Filter by entity type
+
+```typescript
+// Using the type shorthand (recommended)
+brain.find({ type: NounType.Person })
+
+// Using where.noun directly
+brain.find({ where: { noun: NounType.Person } })
+
+// Multiple types
+brain.find({ type: [NounType.Person, NounType.Agent] })
+```
+
+### Filter by subtype
+
+`subtype` is a top-level standard field — takes the column-store fast path, not the metadata fallback. Pair with `type` for the typical "Person who is an employee" query:
+
+```typescript
+// Equality on subtype:
+brain.find({ type: NounType.Person, subtype: 'employee' })
+
+// Set membership:
+brain.find({ type: NounType.Person, subtype: ['employee', 'contractor'] })
+
+// Operator-form predicates use `where`:
+brain.find({
+  type: NounType.Person,
+  where: { subtype: { exists: true } }
+})
+```
+
+See the **[Subtypes & Facets guide](./guides/subtypes-and-facets.md)** for the full surface.
+
+### Filter relationships by subtype (7.30+)
+
+Verbs are first-class peers — `related()` and graph traversal both honor subtype filters on the fast path:
+
+```typescript
+// Filter relationships by VerbType subtype
+const direct = await brain.related({
+  from: ceoId,
+  type: VerbType.ReportsTo,
+  subtype: 'direct'
+})
+
+// Set membership on verb subtype
+const all = await brain.related({
+  from: ceoId,
+  type: VerbType.ReportsTo,
+  subtype: ['direct', 'dotted-line']
+})
+
+// Graph traversal — subtype filters traversal edges (depth-1 in 7.30 JS path;
+// multi-hop subtype filtering lands on Cor native)
+const reports = await brain.find({
+  connected: {
+    from: ceoId,
+    via: VerbType.ReportsTo,
+    subtype: 'direct',
+    depth: 1
+  }
+})
+```
+
+### Combine semantic search with filters
+
+```typescript
+const results = await brain.find({
+  query: 'machine learning engineer',     // Semantic search (on data)
+  type: NounType.Person,                  // Type filter (indexed)
+  where: {
+    department: 'engineering',            // Exact match (indexed)
+    yearsExperience: { greaterThan: 3 }   // Range filter (indexed)
+  },
+  limit: 10
+})
+```
+
+### Temporal queries
+
+```typescript
+const lastWeek = Date.now() - 7 * 24 * 60 * 60 * 1000
+const recentEntities = await brain.find({
+  where: {
+    createdAt: { greaterThan: lastWeek }
+  },
+  orderBy: 'createdAt',
+  order: 'desc',
+  limit: 50
+})
+```
+
+### Graph + metadata combination
+
+```typescript
+const results = await brain.find({
+  connected: {
+    from: teamLeadId,
+    via: VerbType.WorksWith,
+    depth: 2
+  },
+  where: {
+    role: { oneOf: ['engineer', 'designer'] },
+    active: true
+  }
+})
+```
+
+---
+
+## See Also
+
+- [Data Model](./DATA_MODEL.md) — Entity structure, data vs metadata
+- [API Reference](./api/README.md) — Complete API documentation
+- [Find System](./FIND_SYSTEM.md) — Natural language find() details

docs/README.md

@@ -0,0 +1,130 @@
+# Brainy Documentation
+
+> The multi-dimensional AI database with Triple Intelligence — vector search, graph traversal, and metadata filtering in one unified API.
+
+## Quick Start
+
+```typescript
+import { Brainy, NounType, VerbType } from '@soulcraft/brainy'
+
+const brain = new Brainy()
+await brain.init()
+
+// Add entities — data is embedded for semantic search, metadata is indexed for filtering
+const id = await brain.add({
+  data: 'Revolutionary AI Breakthrough',
+  type: NounType.Document,
+  metadata: { category: 'technology', rating: 4.8 }
+})
+
+// Search with Triple Intelligence
+const results = await brain.find({
+  query: 'artificial intelligence',              // Semantic search (on data)
+  where: { rating: { greaterThan: 4.0 } },       // Metadata filter
+  connected: { from: authorId, depth: 2 }         // Graph traversal
+})
+```
+
+---
+
+## Core Documentation
+
+| Document | Description |
+|----------|-------------|
+| **[API Reference](./api/README.md)** | Complete API documentation — **start here** |
+| **[Data Model](./DATA_MODEL.md)** | Entity structure, data vs metadata, storage fields |
+| **[Query Operators](./QUERY_OPERATORS.md)** | All BFO operators with examples and indexed/in-memory matrix |
+| [Find System](./FIND_SYSTEM.md) | Natural language `find()` and hybrid search details |
+| [Consistency Model](./concepts/consistency-model.md) | The Db API guarantees — snapshot isolation, atomic transactions, time travel |
+
+---
+
+## Architecture
+
+| Document | Description |
+|----------|-------------|
+| [Architecture Overview](./architecture/overview.md) | High-level system design |
+| [Triple Intelligence](./architecture/triple-intelligence.md) | Vector + Graph + Metadata unified query |
+| [Noun-Verb Taxonomy](./architecture/noun-verb-taxonomy.md) | 42 nouns + 127 verbs type system |
+| [Stage 3 Canonical Taxonomy](./STAGE3-CANONICAL-TAXONOMY.md) | Complete type reference |
+| [Storage Architecture](./architecture/storage-architecture.md) | Storage adapters and optimization |
+| [Index Architecture](./architecture/index-architecture.md) | Vector, Graph, and Metadata indexing |
+| [Zero Configuration](./architecture/zero-config.md) | Auto-adapts to any environment |
+
+---
+
+## Virtual Filesystem (VFS)
+
+| Document | Description |
+|----------|-------------|
+| [VFS Quick Start](./vfs/QUICK_START.md) | Get started in 30 seconds |
+| [VFS Core](./vfs/VFS_CORE.md) | Core concepts and architecture |
+| [VFS API Guide](./vfs/VFS_API_GUIDE.md) | Complete VFS API reference |
+| [Common Patterns](./vfs/COMMON_PATTERNS.md) | VFS usage patterns |
+
+See [vfs/](./vfs/) for the complete VFS documentation set.
+
+---
+
+## Guides
+
+| Document | Description |
+|----------|-------------|
+| [Import Anything](./guides/import-anything.md) | CSV, Excel, PDF, URL imports |
+| [Snapshots & Time Travel](./guides/snapshots-and-time-travel.md) | Backups, restore, what-if analysis, audit trails |
+| [Natural Language](./guides/natural-language.md) | Query in plain English |
+| [Neural API](./guides/neural-api.md) | AI-powered features |
+| [Enterprise for Everyone](./guides/enterprise-for-everyone.md) | No limits, no tiers |
+| [Framework Integration](./guides/framework-integration.md) | React, Vue, Angular, Svelte |
+
+---
+
+## Storage & Deployment
+
+| Document | Description |
+|----------|-------------|
+| [Storage Architecture](./architecture/storage-architecture.md) | Filesystem and memory adapters, on-disk artifact layout, operator-layer backup |
+| [Capacity Planning](./operations/capacity-planning.md) | Scale to millions of entities |
+
+---
+
+## Plugins
+
+| Document | Description |
+|----------|-------------|
+| [Plugins](./PLUGINS.md) | Plugin system overview — providers, `plugins` config, `brain.use()` |
+
+---
+
+## Performance & Scaling
+
+| Document | Description |
+|----------|-------------|
+| [Performance](./PERFORMANCE.md) | Optimization techniques |
+| [Scaling](./SCALING.md) | Scale to billions of entities |
+| [Batching](./BATCHING.md) | Batch operations guide |
+
+---
+
+## Migration & Reference
+
+| Document | Description |
+|----------|-------------|
+| [v3 to v4 Migration](./MIGRATION-V3-TO-V4.md) | Upgrade guide |
+| [Release Guide](./RELEASE-GUIDE.md) | How to release new versions |
+| [Production Architecture](./PRODUCTION_SERVICE_ARCHITECTURE.md) | Ops reference |
+
+---
+
+## Internal
+
+| Document | Description |
+|----------|-------------|
+| [Audit Report](./internal/AUDIT_REPORT.md) | Feature audit |
+| [Honest Status](./internal/HONEST_STATUS.md) | Actual implementation status |
+
+---
+
+## License
+
+Brainy is MIT licensed. See [LICENSE](../LICENSE) for details.

docs/RELEASE-GUIDE.md

@@ -0,0 +1,131 @@
+# Brainy Release Guide
+
+## Standard Semantic Versioning (Industry Guidelines)
+
+### Official SemVer 2.0.0 says:
+- **MAJOR**: Incompatible API changes (breaking changes)
+- **MINOR**: Add functionality in backwards compatible manner
+- **PATCH**: Backwards compatible bug fixes
+
+## Our Approach for Brainy (More Conservative)
+
+### We intentionally diverge from strict SemVer:
+- **PATCH (2.3.0 → 2.3.1)**: Bug fixes, internal improvements, dependency updates
+- **MINOR (2.3.0 → 2.4.0)**: New features, API changes, enhancements
+- **MAJOR (3.0.0)**: Reserved for strategic platform shifts (manual decision)
+
+### Why We Do This:
+1. **User Trust**: Major versions signal huge changes and scare users
+2. **Adoption**: People hesitate to upgrade major versions
+3. **Flexibility**: We can evolve the API without version explosion
+4. **Industry Practice**: Many successful projects (React, Vue) do this
+
+## CRITICAL: Never Use "BREAKING CHANGE" 
+
+**"BREAKING CHANGE" in commits = Automatic major version = BAD!**
+- Even if removing methods, just use `feat:` or `refactor:`
+- Major versions are MANUAL decisions: `npm run release:major`
+- Most API changes can be handled gracefully in minor versions
+
+## Commit Message Guidelines
+
+### ✅ CORRECT Examples:
+```bash
+# New features → MINOR bump
+git commit -m "feat: add new model delivery system"
+
+# Bug fixes → PATCH bump
+git commit -m "fix: resolve model download timeout"
+
+# Internal improvements → PATCH bump
+git commit -m "refactor: simplify model manager logic"
+git commit -m "perf: optimize model caching"
+git commit -m "chore: remove unused dependency"
+```
+
+### ❌ AVOID These Mistakes:
+```bash
+# DON'T use BREAKING CHANGE for internal changes
+git commit -m "feat: improve model delivery
+
+BREAKING CHANGE: removed tar-stream dependency"  # WRONG! This triggers
+```
+
+## Release Workflow Checklist
+
+### Before Committing:
+- [ ] Review commit message - no "BREAKING CHANGE" unless API changes
+- [ ] Consider: Will users need to change their code? If NO → Not breaking
+
+### Release Commands:
+```bash
+# Let standard-version figure it out from commits
+npm run release              # Recommended - auto-detects version
+
+# Or be explicit:
+npm run release:patch        # 2.4.0 → 2.4.1 (fixes)
+npm run release:minor        # 2.4.0 → 2.5.0 (features)
+npm run release:major        # 2.4.0 → 3.0.0 (API changes only!)
+```
+
+### After Release:
+```bash
+git push --follow-tags origin main
+npm publish
+gh release create $(git describe --tags --abbrev=0) --generate-notes
+```
+
+## When to Use Major Version (3.0.0)
+
+ONLY when we make changes like:
+- Removing methods from the public API
+- Changing method signatures (parameters, return types)
+- Renaming public methods
+- Changing default behaviors that break existing code
+
+Examples:
+- ❌ `search(query, limit, options)` → `search(query, options)` (major)
+- ✅ Adding `find()` method (minor - doesn't break existing code)
+- ✅ Internal refactoring (patch - users don't see it)
+
+## Quick Decision Tree
+
+1. **Does this fix a bug?** → PATCH (fix:)
+2. **Does this add new functionality?** → MINOR (feat:)
+3. **Will users' existing code break?** → MAJOR (with BREAKING CHANGE)
+4. **Is it internal/maintenance?** → PATCH (chore:/refactor:/perf:)
+
+## Emergency: If Wrong Version is Released
+
+```bash
+# 1. Deprecate wrong version on npm
+npm deprecate @soulcraft/brainy@X.X.X "Incorrect version - use Y.Y.Y"
+
+# 2. Fix version in package.json
+# 3. Republish correct version
+npm publish
+
+# 4. Delete wrong GitHub tag/release
+git push origin :vX.X.X
+gh release delete vX.X.X --yes
+
+# 5. Create correct tag/release
+git tag vY.Y.Y
+git push --tags
+gh release create vY.Y.Y --generate-notes
+```
+
+## Remember:
+- **Most releases should be MINOR or PATCH**
+- **Major versions should be RARE**
+- **When in doubt, it's probably MINOR**
+- **NEVER use "BREAKING CHANGE" for internal changes**
+## Hard Ordering Constraints (check before EVERY release)
+
+- **Embedding model changes are SEQUENCED, not free.** No release may change the
+  embedding model (or its quantization/dimensions) before **vector model-version
+  stamping + hard-error-on-mismatch** ships. Stored vectors carry no model version
+  today; mixing vectors from two models silently corrupts every similarity
+  comparison. If a model bump is ever proposed, the stamping work moves ahead of
+  it in the schedule — coordinate with the native provider so both engines stamp
+  and enforce identically. (Registered with the native-provider team 2026-07-07.)

docs/SCALING.md

@@ -0,0 +1,239 @@
+# Brainy Scaling Guide
+
+> **One Line Summary**: Single-node by design — Brainy scales by getting the most out of one machine plus operator-layer backup.
+
+## Table of Contents
+- [Quick Start](#quick-start)
+- [How Brainy Scales](#how-brainy-scales)
+- [Storage Configurations](#storage-configurations)
+- [Scaling Patterns](#scaling-patterns)
+- [Real World Examples](#real-world-examples)
+
+## Quick Start
+
+### In-Memory
+```typescript
+import Brainy from '@soulcraft/brainy'
+const brain = new Brainy({ storage: { type: 'memory' } })
+```
+
+### On-Disk (Default for Node)
+```typescript
+const brain = new Brainy({
+  storage: { type: 'filesystem', path: './brainy-data' }
+})
+```
+
+## How Brainy Scales
+
+Brainy 8.0 is a **single-node library**. There is no cluster, no peer discovery, no S3 coordination. Scaling means:
+
+- **Up**: give the process more RAM, CPU, and IOPS
+- **Out**: stand up multiple independent Brainy instances behind your own service layer
+- **Cold storage**: snapshot the on-disk artifact off-site so you can rehydrate elsewhere
+
+The three knobs that matter most:
+
+1. **`config.vector.recall`** — `'fast'`, `'balanced'`, or `'accurate'` (default `'balanced'`)
+2. **`config.vector.persistMode`** — `'immediate'` for durability, `'deferred'` for throughput
+
+The native vector provider (via the optional `@soulcraft/cor` package) extends this with a higher-performing index — and its own at-scale acceleration such as on-disk compressed indexing — when installed.
+
+## Measured Performance
+
+Numbers below are **measured** by `tests/benchmarks/find-composition-scale.js` (a single
+Node 22 process, in-memory storage, 384-dim vectors, `balanced` recall). They are the
+open-core (pure-TypeScript) path — what you get from `@soulcraft/brainy` with no native
+provider installed. Run it yourself: `node --max-old-space-size=8192 tests/benchmarks/find-composition-scale.js 100000`.
+
+`find()` query latency, p50 / p95 (200 queries each):
+
+| Query | 5,000 entities | 100,000 entities |
+|---|---|---|
+| Vector similarity (`{ vector }`) | 0.8 / 1.3 ms | 1.4 / 4.7 ms |
+| Graph 1-hop (`{ connected }`) | 0.5 / 0.7 ms | 0.7 / 0.8 ms |
+| Metadata filter (`{ where }`, low-selectivity) | 0.7 / 1.2 ms | 23.5 / 30.1 ms |
+| Vector + metadata | 7.7 / 8.3 ms | 78.8 / 93.8 ms |
+
+What the shape tells you:
+
+- **Vector and graph lookups scale ~logarithmically** — they barely move from 5k to 100k,
+  because HNSW search is ~O(ef·log n) and graph adjacency is O(degree).
+- **Metadata-filtered paths scale with the size of the match set, not the database.** The
+  benchmark's `category` filter matches ~10% of rows (10,000 at 100k); the cost is
+  materializing that candidate set and running the vector search *inside* it (`find()` does
+  metadata-first hard filtering, then ranks within the candidates — see
+  [How find works](./FIND_SYSTEM.md)). A **high-selectivity** filter (few matches) is far
+  cheaper; a 10%-of-everything filter is the worst case. This candidate-restricted search is
+  precisely the path the native provider accelerates (Rust roaring-bitmap candidate
+  intersection).
+- **Composition is correct, not lossy.** Combining vector + metadata + graph returns exactly
+  the entities satisfying all constraints — verified by
+  `tests/integration/find-triple-composition.test.ts`.
+
+Memory: ~62 KB resident per entity at 100k (6.2 GB RSS for 100k × 384-dim including the HNSW
+graph, metadata index, and 100k edges).
+
+**Scale ceiling (open-core).** The pure-JS HNSW *build* cost (~100 inserts/s at 384-dim on
+one core) makes the in-process open-core path most appropriate up to ~10⁵–10⁶ entities.
+*Query* latency stays low well beyond that, but for the 10⁸–10¹⁰ regime install the native
+provider (`@soulcraft/cor`, on-disk DiskANN) — same API, no code change. _Projected from
+the two measured points, vector p50 at 1M is ~2 ms; metadata-heavy composition grows with
+match-set size and is the path to move onto the native provider first._
+
+## Storage Configurations
+
+### Filesystem (Recommended for Production)
+```typescript
+const brain = new Brainy({
+  storage: {
+    type: 'filesystem',
+    path: '/var/lib/brainy'
+  }
+})
+```
+- Stores everything in a sharded JSON tree under `path`
+- Atomic writes via rename
+- Survives process restarts
+- Snapshot it off-site with `gsutil rsync`, `aws s3 sync`, `rclone`, or `tar` from your scheduler
+
+### Memory
+```typescript
+const brain = new Brainy({ storage: { type: 'memory' } })
+```
+- Zero I/O, fastest possible
+- No persistence — process exit discards everything
+- Use for tests and ephemeral caches
+
+### Auto
+```typescript
+const brain = new Brainy({
+  storage: { type: 'auto', path: './data' }
+})
+```
+- Picks `filesystem` when running on Node with a writable `path`
+- Falls back to `memory` otherwise
+
+## Scaling Patterns
+
+### Stage 1: Prototype (Memory)
+```typescript
+const brain = new Brainy({ storage: { type: 'memory' } })
+// Development, tests, <100K items
+```
+
+### Stage 2: Production (Filesystem)
+```typescript
+const brain = new Brainy({
+  storage: { type: 'filesystem', path: '/var/lib/brainy' }
+})
+// Most production workloads up to ~10M entities on a single host
+```
+
+### Stage 3: Higher Throughput (Tune the Vector Index)
+```typescript
+const brain = new Brainy({
+  storage: { type: 'filesystem', path: '/var/lib/brainy' },
+  vector: {
+    recall: 'fast',                // Trade recall for latency
+    persistMode: 'deferred'        // Batch persistence
+  }
+})
+```
+
+### Stage 4: Multi-Instance (Operator-Layer)
+Run multiple Brainy processes behind your own routing/service layer. Each process owns its own `path`. Sync each artifact off-site independently. Brainy itself does not coordinate between processes.
+
+## Real World Examples
+
+### Example 1: Single-Node App With Backup
+```typescript
+const brain = new Brainy({
+  storage: { type: 'filesystem', path: '/var/lib/brainy' }
+})
+```
+Schedule (cron / systemd timer):
+```bash
+*/15 * * * *  rclone sync /var/lib/brainy remote:brainy-backup
+```
+
+### Example 2: Tests
+```typescript
+const brain = new Brainy({ storage: { type: 'memory' } })
+// Fast, no cleanup needed between runs
+```
+
+### Example 3: Multi-Tenant Service
+Spin up one Brainy instance per tenant, each in its own directory:
+```typescript
+function brainForTenant(tenantId: string) {
+  return new Brainy({
+    storage: {
+      type: 'filesystem',
+      path: `/var/lib/brainy/${tenantId}`
+    }
+  })
+}
+```
+Your service layer handles routing and isolation; Brainy stays simple.
+
+### Example 4: Higher Recall at Scale
+```typescript
+const brain = new Brainy({
+  storage: { type: 'filesystem', path: '/var/lib/brainy' },
+  vector: {
+    recall: 'accurate'
+  }
+})
+```
+
+## Tuning Knobs Summary
+
+| Setting | Values | When to change |
+|---------|--------|----------------|
+| `vector.recall` | `'fast'` / `'balanced'` / `'accurate'` | Trade recall for latency |
+| `vector.persistMode` | `'immediate'` / `'deferred'` | Throughput vs. durability |
+| `storage.cache.maxSize` | integer | Hot-path read cache size |
+| `storage.cache.ttl` | ms | Cache freshness |
+
+## Monitoring & Observability
+
+```typescript
+const stats = await brain.stats()
+// {
+//   nounCount: 50000,
+//   verbCount: 80000,
+//   vectorIndex: { ... },
+//   storage: { used: '45GB' }
+// }
+```
+
+## Troubleshooting
+
+### Issue: Slow queries
+1. Switch to `vector.recall: 'fast'`
+2. Increase the read cache (`storage.cache.maxSize`)
+3. Consider the optional native vector provider via `@soulcraft/cor`
+
+### Issue: Memory pressure
+1. Reduce `storage.cache.maxSize`
+2. Move to `vector.persistMode: 'deferred'` to batch writes
+3. Consider the optional native vector provider via `@soulcraft/cor` for at-scale index acceleration
+
+### Issue: Slow startup after a crash
+1. Use `vector.persistMode: 'immediate'` so the index file stays in sync with storage
+2. Verify backup integrity periodically
+
+## Best Practices
+
+1. **One process = one `path`** — never share a directory between processes
+2. **Snapshot from your scheduler** — Brainy doesn't ship cloud SDKs; use `rclone` / `aws s3 sync` / `gsutil`
+3. **Profile before tuning** — `recall: 'balanced'` is right for most workloads
+4. **Install the native vector provider only when measured profiling shows it pays off**
+
+## Summary
+
+- Brainy 8.0 is a **library**, not a cluster
+- Storage adapters: `filesystem`, `memory`, `auto`
+- Vector tuning: `recall`, `persistMode`
+- Backup is an operator-layer concern — snapshot `path`

docs/STAGE3-CANONICAL-TAXONOMY.md

@@ -0,0 +1,373 @@
+# Brainy Stage 3: Canonical Taxonomy
+
+**Status:** FINAL - This is the definitive, timeless taxonomy
+**Total Types:** 169 (42 nouns + 127 verbs)
+**Coverage:** 96-97% of all human knowledge
+**Designed to last:** 20+ years without changes
+
+---
+
+## Summary
+
+- **Nouns:** 42 types
+- **Verbs:** 127 types
+- **Total:** 169 types
+- **Previous (v5.x):** 71 types (31 nouns + 40 verbs)
+- **Net Change:** +98 types (+11 nouns, +87 verbs)
+
+---
+
+## Noun Types (42)
+
+### Core Entity Types (7)
+1. **person** - Individual human entities
+2. **organization** - Collective entities, companies, institutions
+3. **location** - Geographic and named spatial entities
+4. **thing** - Discrete physical objects and artifacts
+5. **concept** - Abstract ideas, principles, and intangibles
+6. **event** - Temporal occurrences and happenings
+7. **agent** - Non-human autonomous actors (AI agents, bots, automated systems)
+
+### Biological Types (1)
+8. **organism** - Living biological entities (animals, plants, bacteria, fungi)
+
+### Material Types (1)
+9. **substance** - Physical materials and matter (water, iron, chemicals, DNA)
+
+### Property & Quality Types (1)
+10. **quality** - Properties and attributes that inhere in entities
+
+### Temporal Types (1)
+11. **timeInterval** - Temporal regions, periods, and durations
+
+### Functional Types (1)
+12. **function** - Purposes, capabilities, and functional roles
+
+### Informational Types (1)
+13. **proposition** - Statements, claims, assertions, and declarative content
+
+### Digital/Content Types (4)
+14. **document** - Text-based files and written content
+15. **media** - Non-text media files (audio, video, images)
+16. **file** - Generic digital files and data blobs
+17. **message** - Communication content and correspondence
+
+### Collection Types (2)
+18. **collection** - Groups and sets of items
+19. **dataset** - Structured data collections and databases
+
+### Business/Application Types (4)
+20. **product** - Commercial products and offerings
+21. **service** - Service offerings and intangible products
+22. **task** - Actions, todos, and work items
+23. **project** - Organized initiatives and programs
+
+### Descriptive Types (6)
+24. **process** - Workflows, procedures, and ongoing activities
+25. **state** - Conditions, status, and situational contexts
+26. **role** - Positions, responsibilities, and functional classifications
+27. **language** - Natural and formal languages
+28. **currency** - Monetary units and exchange mediums
+29. **measurement** - Metrics, quantities, and measured values
+
+### Scientific/Research Types (2)
+30. **hypothesis** - Scientific theories, propositions, and conjectures
+31. **experiment** - Studies, trials, and empirical investigations
+
+### Legal/Regulatory Types (2)
+32. **contract** - Legal agreements, terms, and binding documents
+33. **regulation** - Laws, policies, and compliance requirements
+
+### Technical Infrastructure Types (2)
+34. **interface** - APIs, protocols, and connection points
+35. **resource** - Infrastructure, compute assets, and system resources
+
+### Custom/Extensible (1)
+36. **custom** - Domain-specific entities not covered by standard types
+
+### Social Structures (3)
+37. **socialGroup** - Informal social groups and collectives
+38. **institution** - Formal social structures and practices
+39. **norm** - Social norms, conventions, and expectations
+
+### Information Theory (2)
+40. **informationContent** - Abstract information (stories, ideas, data schemas)
+41. **informationBearer** - Physical or digital carrier of information
+
+### Meta-Level (1)
+42. **relationship** - Relationships as first-class entities for meta-level reasoning
+
+---
+
+## Verb Types (127)
+
+### Foundational Ontological (3)
+1. **instanceOf** - Individual to class relationship
+2. **subclassOf** - Taxonomic hierarchy
+3. **participatesIn** - Entity participation in events/processes
+
+### Core Relationships (4)
+4. **relatedTo** - Generic relationship (fallback)
+5. **contains** - Containment relationship
+6. **partOf** - Part-whole mereological relationship
+7. **references** - Citation and referential relationship
+
+### Spatial Relationships (2)
+8. **locatedAt** - Spatial location relationship
+9. **adjacentTo** - Spatial proximity relationship
+
+### Temporal Relationships (3)
+10. **precedes** - Temporal sequence (before)
+11. **during** - Temporal containment
+12. **occursAt** - Temporal location
+
+### Causal & Dependency (5)
+13. **causes** - Direct causal relationship
+14. **enables** - Enablement without direct causation
+15. **prevents** - Prevention relationship
+16. **dependsOn** - Dependency relationship
+17. **requires** - Necessity relationship
+
+### Creation & Transformation (5)
+18. **creates** - Creation relationship
+19. **transforms** - Transformation relationship
+20. **becomes** - State change relationship
+21. **modifies** - Modification relationship
+22. **consumes** - Consumption relationship
+
+### Lifecycle Operations (1)
+23. **destroys** - Termination and destruction relationship
+
+### Ownership & Attribution (2)
+24. **owns** - Ownership relationship
+25. **attributedTo** - Attribution relationship
+
+### Property & Quality (2)
+26. **hasQuality** - Entity to quality attribution
+27. **realizes** - Function realization relationship
+
+### Effects & Experience (1)
+28. **affects** - Patient/experiencer relationship
+
+### Composition (2)
+29. **composedOf** - Material composition
+30. **inherits** - Inheritance relationship
+
+### Social & Organizational (7)
+31. **memberOf** - Membership relationship
+32. **worksWith** - Professional collaboration
+33. **friendOf** - Friendship relationship
+34. **follows** - Following/subscription relationship
+35. **likes** - Liking/favoriting relationship
+36. **reportsTo** - Hierarchical reporting relationship
+37. **mentors** - Mentorship relationship
+38. **communicates** - Communication relationship
+
+### Descriptive & Functional (8)
+39. **describes** - Descriptive relationship
+40. **defines** - Definition relationship
+41. **categorizes** - Categorization relationship
+42. **measures** - Measurement relationship
+43. **evaluates** - Evaluation relationship
+44. **uses** - Utilization relationship
+45. **implements** - Implementation relationship
+46. **extends** - Extension relationship
+
+### Advanced Relationships (4)
+47. **equivalentTo** - Equivalence/identity relationship
+48. **believes** - Epistemic relationship
+49. **conflicts** - Conflict relationship
+50. **synchronizes** - Synchronization relationship
+51. **competes** - Competition relationship
+
+### Modal Relationships (6)
+52. **canCause** - Potential causation (possibility)
+53. **mustCause** - Necessary causation (necessity)
+54. **wouldCauseIf** - Counterfactual causation
+55. **couldBe** - Possible states
+56. **mustBe** - Necessary identity
+57. **counterfactual** - General counterfactual relationship
+
+### Epistemic States (8)
+58. **knows** - Knowledge (justified true belief)
+59. **doubts** - Uncertainty/skepticism
+60. **desires** - Want/preference
+61. **intends** - Intentionality
+62. **fears** - Fear/anxiety
+63. **loves** - Strong positive emotional attitude
+64. **hates** - Strong negative emotional attitude
+65. **hopes** - Hopeful expectation
+66. **perceives** - Sensory perception
+
+### Learning & Cognition (1)
+67. **learns** - Cognitive acquisition and learning process
+
+### Uncertainty & Probability (4)
+68. **probablyCauses** - Probabilistic causation
+69. **uncertainRelation** - Unknown relationship with confidence bounds
+70. **correlatesWith** - Statistical correlation
+71. **approximatelyEquals** - Fuzzy equivalence
+
+### Scalar Properties (5)
+72. **greaterThan** - Scalar comparison
+73. **similarityDegree** - Graded similarity
+74. **moreXThan** - Comparative property
+75. **hasDegree** - Scalar property assignment
+76. **partiallyHas** - Graded possession
+
+### Information Theory (2)
+77. **carries** - Bearer carries content
+78. **encodes** - Encoding relationship
+
+### Deontic Relationships (5)
+79. **obligatedTo** - Moral/legal obligation
+80. **permittedTo** - Permission/authorization
+81. **prohibitedFrom** - Prohibition/forbidden
+82. **shouldDo** - Normative expectation
+83. **mustNotDo** - Strong prohibition
+
+### Context & Perspective (5)
+84. **trueInContext** - Context-dependent truth
+85. **perceivedAs** - Subjective perception
+86. **interpretedAs** - Interpretation relationship
+87. **validInFrame** - Frame-dependent validity
+88. **trueFrom** - Perspective-dependent truth
+
+### Advanced Temporal (6)
+89. **overlaps** - Partial temporal overlap
+90. **immediatelyAfter** - Direct temporal succession
+91. **eventuallyLeadsTo** - Long-term consequence
+92. **simultaneousWith** - Exact temporal alignment
+93. **hasDuration** - Temporal extent
+94. **recurringWith** - Cyclic temporal relationship
+
+### Advanced Spatial (7)
+95. **containsSpatially** - Spatial containment
+96. **overlapsSpatially** - Spatial overlap
+97. **surrounds** - Encirclement
+98. **connectedTo** - Topological connection
+99. **above** - Vertical spatial relationship (superior)
+100. **below** - Vertical spatial relationship (inferior)
+101. **inside** - Within containment boundaries
+102. **outside** - Beyond containment boundaries
+103. **facing** - Directional orientation
+
+### Social Structures (5)
+104. **represents** - Representative relationship
+105. **embodies** - Exemplification or personification
+106. **opposes** - Opposition relationship
+107. **alliesWith** - Alliance relationship
+108. **conformsTo** - Norm conformity
+
+### Measurement (4)
+109. **measuredIn** - Unit relationship
+110. **convertsTo** - Unit conversion
+111. **hasMagnitude** - Quantitative value
+112. **dimensionallyEquals** - Dimensional analysis
+
+### Change & Persistence (4)
+113. **persistsThrough** - Persistence through change
+114. **gainsProperty** - Property acquisition
+115. **losesProperty** - Property loss
+116. **remainsSame** - Identity through time
+
+### Parthood Variations (4)
+117. **functionalPartOf** - Functional component
+118. **topologicalPartOf** - Spatial part
+119. **temporalPartOf** - Temporal slice
+120. **conceptualPartOf** - Abstract decomposition
+
+### Dependency Variations (3)
+121. **rigidlyDependsOn** - Necessary dependency
+122. **functionallyDependsOn** - Operational dependency
+123. **historicallyDependsOn** - Causal history dependency
+
+### Meta-Level (4)
+124. **endorses** - Second-order validation
+125. **contradicts** - Logical contradiction
+126. **supports** - Evidential support
+127. **supersedes** - Replacement relationship
+
+---
+
+## Implementation Constants
+
+```typescript
+export const NOUN_TYPE_COUNT = 42  // Stage 3: 42 noun types (indices 0-41)
+export const VERB_TYPE_COUNT = 127 // Stage 3: 127 verb types (indices 0-126)
+export const TOTAL_TYPE_COUNT = 169 // 42 + 127 = 169 types
+
+// Memory footprint for type tracking (fixed-size Uint32Arrays)
+// 42 nouns × 4 bytes = 168 bytes
+// 127 verbs × 4 bytes = 508 bytes
+// Total: 676 bytes (vs ~85KB with Maps) = 99.2% memory reduction
+```
+
+---
+
+## Changes from v5.x
+
+### Nouns Added (+11)
+- agent, quality, timeInterval, function, proposition
+- **organism** ⭐ (biological entities)
+- **substance** ⭐ (physical materials)
+- socialGroup, institution, norm
+- informationContent, informationBearer, relationship
+
+### Nouns Removed (-2)
+- **user** (merged into person)
+- **topic** (merged into concept)
+- **content** (removed - redundant)
+
+### Verbs Added (+87)
+- **affects** ⭐ (patient/experiencer role)
+- **learns** ⭐ (cognitive acquisition)
+- **destroys** ⭐ (lifecycle termination)
+- All new categories from Stage 3 taxonomy
+
+### Verbs Removed (-4)
+- **succeeds** (use inverse of precedes)
+- **belongsTo** (use inverse of owns)
+- **createdBy** (use inverse of creates)
+- **supervises** (use inverse of reportsTo)
+
+⭐ = Critical additions from ultradeep analysis
+
+---
+
+## Coverage & Completeness
+
+**Domain Coverage:**
+- Natural Sciences: 96% (physics, chemistry, biology, medicine)
+- Formal Sciences: 98% (mathematics, logic, computer science)
+- Social Sciences: 97% (psychology, sociology, economics)
+- Humanities: 96% (philosophy, history, arts)
+
+**Overall:** 96-97% of all human knowledge
+
+**Timeless Design:** Stable for 20+ years
+
+**Extension:** Use "custom" noun for domain-specific entities
+
+---
+
+## Verification Checklist
+
+All code, comments, and documentation MUST match this canonical list:
+
+- [ ] graphTypes.ts: NounType has exactly 42 entries
+- [ ] graphTypes.ts: VerbType has exactly 127 entries
+- [ ] graphTypes.ts: NOUN_TYPE_COUNT = 42
+- [ ] graphTypes.ts: VERB_TYPE_COUNT = 127
+- [ ] graphTypes.ts: NounTypeEnum has indices 0-41
+- [ ] graphTypes.ts: VerbTypeEnum has indices 0-126
+- [ ] metadataIndex.ts: Arrays sized for 42 & 127
+- [ ] buildTypeEmbeddings.ts: Descriptions for all 169 types
+- [ ] brainyTypes.ts: Descriptions for all 169 types
+- [ ] index.ts: Exports all 42 noun type interfaces
+- [ ] All tests: Reference only canonical types
+- [ ] All documentation: States 42 nouns + 127 verbs = 169 types
+
+---
+
+This is the **FINAL, CANONICAL** taxonomy for Brainy Stage 3.

docs/architecture/PERFORMANCE_ANALYSIS.md

@@ -0,0 +1,114 @@
+# Brainy Performance Analysis & Optimization
+
+## Current Issues Found
+
+### 1. ❌ CRITICAL: notEquals Operator is O(n)
+```javascript
+// PROBLEM: Gets ALL items to filter
+case 'notEquals':
+  const allItemIds = await this.getAllIds() // O(n) - TERRIBLE!
+```
+
+### 2. ❌ Soft Delete Performance
+- Every query adds `deleted: { notEquals: true }` 
+- This makes EVERY query O(n) instead of O(log n)
+
+### 3. ❌ exists Operator is Inefficient
+```javascript
+case 'exists':
+  // Scans all cache entries - O(n)
+  for (const [key, entry] of this.indexCache.entries()) {
+    if (entry.field === field) {
+      entry.ids.forEach(id => allIds.add(id))
+    }
+  }
+```
+
+### 4. ⚠️ Query Optimizer Not Smart Enough
+- `isSelectiveFilter()` needs to understand which filters are fast
+- Should prioritize O(1) and O(log n) operations
+
+## Performance Characteristics
+
+### ✅ Fast Operations (Keep These)
+| Operation | Complexity | Example |
+|-----------|-----------|---------|
+| Vector Search (HNSW) | O(log n) | `like: "query"` |
+| Exact Match | O(1) | `where: { status: "active" }` |
+| Deleted Filter (NEW) | O(1) | `where: { deleted: false }` |
+| Range Query (sorted) | O(log n) | `where: { year: { gt: 2000 } }` |
+| Graph Traversal | O(k) | `connected: { from: id }` |
+
+### ❌ Slow Operations (Need Fixing)
+| Operation | Current | Should Be | Fix |
+|-----------|---------|-----------|-----|
+| notEquals | O(n) | O(1) or O(log n) | Use complement index |
+| exists | O(n) | O(1) | Maintain field existence bitmap |
+| noneOf | O(n) | O(k) | Use set operations |
+
+## Optimized Architecture
+
+### Solution 1: Positive Indexing for Soft Delete ✅
+```javascript
+// Instead of: deleted !== true (O(n))
+// Use: deleted === false (O(1))
+where: { deleted: false }
+
+// Ensure all items have deleted field
+if (!metadata.deleted) metadata.deleted = false
+```
+
+### Solution 2: Complement Indices for notEquals
+```javascript
+class MetadataIndexManager {
+  // For common notEquals queries, maintain complement sets
+  private complementIndices: Map<string, Set<string>> = new Map()
+  
+  // Example: Track non-deleted items separately
+  private activeItems: Set<string> = new Set()
+  private deletedItems: Set<string> = new Set()
+}
+```
+
+### Solution 3: Field Existence Bitmap
+```javascript
+class FieldExistenceIndex {
+  private fieldBitmaps: Map<string, BitSet> = new Map()
+  
+  hasField(id: string, field: string): boolean {
+    return this.fieldBitmaps.get(field)?.has(id) ?? false
+  }
+}
+```
+
+## Query Execution Strategy
+
+### Progressive Search (When Metadata is Selective)
+```
+1. Field Filter (O(1) or O(log n)) → Small candidate set
+2. Vector Search within candidates (O(k log k))
+3. Fusion if needed
+```
+
+### Parallel Search (When Nothing is Selective)
+```
+1. Vector Search (O(log n)) → Top K results
+2. Graph Traversal (O(m)) → Connected items  
+3. Field Filter (O(1)) → Metadata matches
+4. Fusion: Intersection or Union
+```
+
+## Implementation Priority
+
+1. **DONE** ✅ Fix soft delete to use `deleted: false`
+2. **TODO** 🔧 Optimize notEquals for common fields
+3. **TODO** 🔧 Add field existence index
+4. **TODO** 🔧 Improve query optimizer intelligence
+5. **TODO** 🔧 Add query explain mode for debugging
+
+## Performance Targets
+
+- Vector search: < 10ms for 1M items
+- Metadata filter: < 1ms for exact match
+- Combined query: < 20ms for complex queries
+- Soft delete overhead: < 0.1ms (O(1))

docs/architecture/aggregation.md

@@ -0,0 +1,242 @@
+# Aggregation Architecture
+
+> Write-time incremental aggregation with O(1) reads
+
+## Design Principles
+
+1. **Write-time computation** — aggregates update on every `add()`, `update()`, and `delete()`, not as batch jobs
+2. **Incremental state** — running totals maintained per group, never rescanning the dataset
+3. **Provider interface** — TypeScript engine is the default; plugins can replace it with native implementations
+4. **Zero-allocation reads** — query results are computed from pre-aggregated state
+
+## Component Overview
+
+```
+┌──────────────────────────────────────────────────────────┐
+│                         Brainy                           │
+│                                                          │
+│  add() / update() / delete()                             │
+│          │                                               │
+│          ▼                                               │
+│  ┌──────────────────────┐    ┌────────────────────────┐  │
+│  │  AggregationIndex    │    │  AggregateMaterializer  │  │
+│  │                      │───▶│  (debounced writes)     │  │
+│  │  ├─ definitions Map  │    └────────────────────────┘  │
+│  │  ├─ states Map       │                                │
+│  │  └─ staleMinMax Set  │    ┌────────────────────────┐  │
+│  │                      │    │  timeWindows.ts         │  │
+│  │  Source filter ──────│───▶│  bucketTimestamp()      │  │
+│  │  Group key ──────────│───▶│  parseBucketRange()     │  │
+│  └──────────┬───────────┘    └────────────────────────┘  │
+│             │                                            │
+│             │ provider interface                          │
+│             ▼                                            │
+│  ┌──────────────────────┐                                │
+│  │  AggregationProvider │  (optional, registered by      │
+│  │  ├─ incrementalUpdate│   plugin like @soulcraft/cor)   │
+│  │  ├─ rebuildAggregate │                                │
+│  │  ├─ queryAggregate   │                                │
+│  │  └─ serialize/restore│                                │
+│  └──────────────────────┘                                │
+└──────────────────────────────────────────────────────────┘
+```
+
+## State Management
+
+### Definitions
+
+Registered via `brain.defineAggregate(def)`. Stored in a `Map<string, AggregateDefinition>` keyed by aggregate name. Persisted to storage under `__aggregation_definitions__` on flush.
+
+### Group State
+
+Each aggregate maintains a `Map<string, AggregateGroupState>` where keys are serialized group key values (e.g., `category=food|date=2024-01`). Each group holds per-metric `MetricState`:
+
+```typescript
+interface MetricState {
+  sum: number    // Running total
+  count: number  // Entity count
+  min: number    // Minimum (Infinity if empty)
+  max: number    // Maximum (-Infinity if empty)
+  m2?: number    // Welford's M2 for stddev/variance
+}
+```
+
+### Change Detection
+
+On restart, definition hashes (FNV-1a 32-bit) are compared with the persisted hash. If a definition changed (different groupBy, metrics, or source), the aggregate state is reset and must be rebuilt.
+
+## Write-Time Update Flow
+
+When `brain.add(entity)` is called:
+
+```
+1. For each registered aggregate:
+   ├─ Source filter check (type, service, where)
+   │  └─ Skip if entity doesn't match
+   ├─ Aggregate entity check
+   │  └─ Skip if entity.service === 'brainy:aggregation'
+   │     or entity.metadata.__aggregate is set
+   ├─ Group key computation
+   │  └─ Extract groupBy fields from metadata
+   │     Apply time bucketing for windowed dimensions
+   └─ Metric update
+      └─ For each metric in the definition:
+         ├─ count: increment count
+         ├─ sum/avg: add value to sum, increment count
+         ├─ min/max: compare and update
+         └─ stddev/variance: Welford's online update
+```
+
+### Update Handling
+
+On `brain.update(entity)`, the engine reverses the old entity's contribution and applies the new entity's contribution. This correctly handles:
+
+- **Value changes**: old amount=10, new amount=20 — sum adjusts by +10
+- **Group key changes**: entity moves from category "food" to "drink" — both groups update
+- **Source filter changes**: entity type changes from Event to Document — removed from matching aggregates
+
+### Delete Handling
+
+On `brain.remove(id)`, the engine reverses the entity's contribution:
+
+- `count` and `sum` are decremented
+- `min`/`max` may become stale (marked in `staleMinMax` for lazy recompute)
+- Welford's M2 is updated with the inverse formula
+- Empty groups (all metric counts at zero) are removed
+
+## Algorithms
+
+### Welford's Online Algorithm
+
+Standard deviation and variance use Welford's numerically stable online algorithm with M2 tracking. This computes incrementally without storing individual values:
+
+```
+On add(x):
+  count += 1
+  oldMean = (sum - x) / (count - 1)    // mean before this value
+  sum += x
+  mean = sum / count                     // mean after this value
+  M2 += (x - oldMean) * (x - mean)
+
+On remove(x):
+  oldMean = sum / count
+  sum -= x
+  count -= 1
+  newMean = sum / count
+  M2 = max(0, M2 - (x - oldMean) * (x - newMean))
+
+Sample variance = M2 / (count - 1)
+Sample stddev = sqrt(variance)
+```
+
+M2 is clamped to zero on remove to prevent floating-point drift from producing negative values.
+
+### MIN/MAX Handling
+
+The TypeScript engine uses simple comparison for add operations and marks MIN/MAX as potentially stale on delete (since removing the current min/max value requires a rescan). Stale values are lazily recomputed on the next query.
+
+The Cor native engine uses a `BTreeMap<OrderedFloat<f64>, u64>` that tracks the exact frequency of every value, providing precise MIN/MAX after any sequence of operations without rescanning.
+
+### Time Window Bucketing
+
+Timestamps (Unix milliseconds) are bucketed using UTC-based formatting:
+
+| Granularity | Bucket Key | Algorithm |
+|------------|-----------|-----------|
+| `hour` | `2024-01-15T14` | UTC year-month-day-hour |
+| `day` | `2024-01-15` | UTC year-month-day |
+| `week` | `2024-W03` | ISO 8601 week (Monday start, week 1 contains first Thursday) |
+| `month` | `2024-01` | UTC year-month |
+| `quarter` | `2024-Q1` | `ceil((month) / 3)` |
+| `year` | `2024` | UTC year |
+| `{ seconds: N }` | ISO timestamp | `floor(timestamp / interval) * interval` |
+
+Bucket keys can be parsed back into `{ start, end }` timestamp ranges via `parseBucketRange()`.
+
+## Provider Interface
+
+The `AggregationProvider` interface defines the contract between Brainy's `AggregationIndex` and plugin-provided native implementations:
+
+```typescript
+interface AggregationProvider {
+  defineAggregate?(def: AggregateDefinition): void
+  removeAggregate?(name: string): void
+
+  incrementalUpdate(
+    name: string,
+    def: AggregateDefinition,
+    entity: Record<string, unknown>,
+    op: 'add' | 'update' | 'delete',
+    prev?: Record<string, unknown>
+  ): AggregateGroupState[]
+
+  computeGroupKey(
+    entity: Record<string, unknown>,
+    groupBy: GroupByDimension[]
+  ): Record<string, string | number>
+
+  rebuildAggregate(
+    def: AggregateDefinition,
+    entities: Array<Record<string, unknown>>
+  ): Map<string, AggregateGroupState>
+
+  queryAggregate(
+    state: Map<string, AggregateGroupState>,
+    params: AggregateQueryParams
+  ): AggregateResult[]
+
+  restoreState?(data: string): void
+  serializeState?(): string
+}
+```
+
+When a native provider is registered:
+
+1. `AggregationIndex` delegates `incrementalUpdate()` to the provider instead of running TypeScript logic
+2. Provider returns updated `AggregateGroupState[]` which are applied back into the state maps
+3. Query execution is delegated via `queryAggregate()`
+4. State serialization is delegated via `serializeState()`/`restoreState()`
+
+Brainy retains ownership of the state maps and persistence. The provider handles computation.
+
+## Materialization
+
+The `AggregateMaterializer` converts aggregate group states into `NounType.Measurement` entities:
+
+1. When an aggregate group is updated and `materialize` is enabled, `scheduleMaterialize()` is called
+2. Materialization is debounced (default: 1000ms) to batch rapid updates during ingestion
+3. On trigger, the materializer either creates or updates a `NounType.Measurement` entity
+4. Materialized entities include `service: 'brainy:aggregation'` and `metadata.__aggregate` to prevent infinite loops
+
+Materialized entities are automatically visible through:
+- OData endpoints
+- Google Sheets integration
+- Server-Sent Events (SSE)
+- Webhook notifications
+
+## Persistence
+
+### Storage Keys
+
+| Key | Content |
+|-----|---------|
+| `__aggregation_definitions__` | Array of all definitions with FNV-1a hashes |
+| `__aggregation_state_{name}__` | Per-aggregate group states (array of `AggregateGroupState`) |
+| `__aggregation_native_state__` | Serialized native provider state (JSON string) |
+
+### Lifecycle
+
+1. **`init()`** — Load definitions, compare hashes, load matching state, restore native provider state
+2. **Write operations** — Mark modified aggregates as dirty
+3. **`flush()`** — Persist all dirty aggregate states and native provider state
+4. **`close()`** — Flush and release resources
+
+## Source Files
+
+| File | Purpose |
+|------|---------|
+| `src/aggregation/AggregationIndex.ts` | Core engine: definitions, state, write hooks, query |
+| `src/aggregation/materializer.ts` | Debounced materialization of results as entities |
+| `src/aggregation/timeWindows.ts` | Time bucketing and bucket range parsing |
+| `src/aggregation/index.ts` | Module exports |
+| `src/types/brainy.types.ts` | Type definitions for all aggregation interfaces |

docs/architecture/augmentations-actual.md

@@ -0,0 +1,302 @@
+# Augmentations System - What Actually Exists
+
+> **Important Update**: Investigation reveals Brainy has MORE augmentations than documented!
+
+## ✅ Actually Implemented Augmentations (12+)
+
+Full implementation with crash recovery, checkpointing, and replay.
+```typescript
+// Fully working with all features documented
+```
+
+### 2. Entity Registry Augmentation ✅
+High-performance deduplication using bloom filters.
+```typescript
+import { EntityRegistryAugmentation } from 'brainy'
+// Complete with all features
+```
+
+### 3. Auto-Register Entities Augmentation ✅
+Automatic entity extraction from text.
+```typescript
+import { AutoRegisterEntitiesAugmentation } from 'brainy'
+// Extracts and registers entities automatically
+```
+
+### 4. Intelligent Verb Scoring Augmentation ✅
+Multi-factor relationship strength calculation.
+```typescript
+import { IntelligentVerbScoringAugmentation } from 'brainy'
+// Semantic, temporal, frequency scoring
+```
+
+### 5. Batch Processing Augmentation ✅
+Dynamic batching with adaptive backpressure.
+```typescript
+import { BatchProcessingAugmentation } from 'brainy'
+// Smart batching with flow control
+```
+
+### 6. Connection Pool Augmentation ✅
+Intelligent connection management.
+```typescript
+import { ConnectionPoolAugmentation } from 'brainy'
+// Auto-scaling connection pools
+```
+
+### 7. Request Deduplicator Augmentation ✅
+Prevents duplicate operations.
+```typescript
+import { RequestDeduplicatorAugmentation } from 'brainy'
+// In-flight request deduplication
+```
+
+### 8. WebSocket Conduit Augmentation ✅
+Real-time bidirectional streaming.
+```typescript
+import { WebSocketConduitAugmentation } from 'brainy'
+// Full WebSocket support
+```
+
+### 9. WebRTC Conduit Augmentation ✅
+Peer-to-peer communication.
+```typescript
+import { WebRTCConduitAugmentation } from 'brainy'
+// P2P data channels
+```
+
+### 10. Memory Storage Augmentation ✅
+Optimized in-memory operations.
+```typescript
+import { MemoryStorageAugmentation } from 'brainy'
+// Memory-specific optimizations
+```
+
+### 11. Server Search Augmentation ✅
+Server-side search delegation over a conduit.
+```typescript
+import { ServerSearchConduitAugmentation } from 'brainy'
+// Forwards queries to a remote Brainy server
+```
+
+### 12. Neural Import Augmentation ✅
+AI-powered data understanding and import.
+```typescript
+import { NeuralImportAugmentation } from 'brainy'
+// Full entity detection and classification
+```
+
+## 🎯 Hidden Features in Augmentations
+
+### Neural Import Capabilities (Fully Implemented!)
+```typescript
+const neuralImport = new NeuralImport(brain)
+
+// These ALL work:
+await neuralImport.neuralImport('data.csv')
+await neuralImport.detectEntitiesWithNeuralAnalysis(data)
+await neuralImport.detectNounType(entity)
+await neuralImport.detectRelationships(entities)
+await neuralImport.generateInsights(data)
+```
+
+### Operation Modes (Fully Implemented!)
+```typescript
+// Read-only mode with optimized caching
+const readerMode = new ReaderMode()
+// 80% cache, aggressive prefetch, 1hr TTL
+
+// Write-only mode with batching
+const writerMode = new WriterMode()
+// Large write buffer, batch writes, minimal cache
+
+// Hybrid mode
+const hybridMode = new HybridMode()
+// Balanced for mixed workloads
+```
+
+### Advanced Caching (3-Level System!)
+```typescript
+const cacheManager = new CacheManager({
+  hotCache: { size: 1000, ttl: 60000 },    // L1 - RAM
+  warmCache: { size: 10000, ttl: 300000 }, // L2 - Fast storage
+  coldCache: { size: 100000, ttl: null }   // L3 - Persistent
+})
+```
+
+### Performance Monitoring (Complete!)
+```typescript
+const monitor = new PerformanceMonitor(brain)
+
+// All these metrics work:
+monitor.getMetrics() // Returns comprehensive stats
+monitor.getQueryPatterns() // Query analysis
+monitor.getCacheStats() // Cache performance
+monitor.getThrottlingMetrics() // Rate limiting info
+```
+
+## 📊 Statistics System (Fully Working!)
+
+```typescript
+const stats = await brain.getStats()
+// Returns comprehensive metrics:
+{
+  nouns: {
+    count: number,
+    created: number,
+    updated: number,
+    deleted: number,
+    size: number,
+    avgSize: number
+  },
+  verbs: {
+    count: number,
+    created: number,
+    types: Record<string, number>,
+    weights: { min, max, avg }
+  },
+  vectors: {
+    dimensions: 384,
+    indexSize: number,
+    partitions: number,
+    avgSearchTime: number
+  },
+  cache: {
+    hits: number,
+    misses: number,
+    evictions: number,
+    hitRate: number,
+    hotCacheSize: number,
+    warmCacheSize: number
+  },
+  performance: {
+    operations: number,
+    avgAddTime: number,
+    avgSearchTime: number,
+    avgUpdateTime: number,
+    p95Latency: number,
+    p99Latency: number
+  },
+  storage: {
+    used: number,
+    available: number,
+    compression: number,
+    files: number
+  },
+  throttling: {
+    delays: number,
+    rateLimited: number,
+    backoffMs: number,
+    retries: number
+  }
+}
+```
+
+## 🚀 GPU Support (Partial but Real!)
+
+```typescript
+// GPU detection WORKS:
+const device = await detectBestDevice()
+// Returns: 'cpu' | 'webgpu' | 'cuda'
+
+// WebGPU support in browser:
+if (device === 'webgpu') {
+  // Transformer models can use WebGPU
+}
+
+// CUDA detection in Node:
+if (device === 'cuda') {
+  // Future: GPU acceleration support
+}
+```
+
+## 🔄 Adaptive Systems (All Working!)
+
+### Adaptive Backpressure
+```typescript
+const backpressure = new AdaptiveBackpressure()
+// Automatically adjusts flow based on system load
+```
+
+### Adaptive Socket Manager
+```typescript
+const socketManager = new AdaptiveSocketManager()
+// Dynamic connection pooling based on traffic
+```
+
+### Cache Auto-Configuration
+```typescript
+const cacheConfig = await getCacheAutoConfig()
+// Sizes cache based on available memory
+```
+
+### S3 Throttling Protection
+```typescript
+// Built into S3 storage adapter
+// Automatic exponential backoff
+// Rate limit detection and adaptation
+```
+
+## 🎨 How to Use Hidden Features
+
+### Enable Reader / Writer Modes
+```typescript
+const brain = new Brainy({
+  mode: 'reader' // or 'writer' or 'hybrid'
+})
+```
+
+### Use Neural Import
+```typescript
+const brain = new Brainy({
+  augmentations: [
+    new NeuralImportAugmentation({
+      confidenceThreshold: 0.7,
+      autoDetect: true
+    })
+  ]
+})
+
+// Import with AI understanding
+await brain.neuralImport('data.csv')
+```
+
+### Access Statistics
+```typescript
+// Get comprehensive stats
+const stats = await brain.getStats()
+
+// Get specific service stats
+const nounStats = await brain.getStatistics({ 
+  service: 'nouns' 
+})
+
+// Force refresh
+const freshStats = await brain.getStatistics({ 
+  forceRefresh: true 
+})
+```
+
+## 📝 What Needs Documentation
+
+These features EXIST but need better docs:
+1. Reader / writer operation modes
+2. Neural import full API
+3. 3-level cache configuration
+4. Performance monitoring API
+5. GPU acceleration setup
+6. Advanced statistics queries
+7. Throttling configuration
+8. Backpressure tuning
+
+## 💡 The Truth
+
+Brainy is MORE powerful than its own documentation suggests! Most "missing" features are actually implemented but hidden or not properly exposed. The codebase contains sophisticated systems for:
+- Reader / writer operation modes
+- AI-powered import
+- Advanced caching
+- Performance monitoring
+- GPU support
+- Adaptive optimization
+
+The main work needed is integration and documentation, not implementation!

docs/architecture/augmentations.md

@@ -0,0 +1,494 @@
+# Augmentations System
+
+## Overview
+
+Brainy's Augmentation System provides a powerful plugin architecture that extends core functionality without modifying the base code. Augmentations can intercept, modify, and enhance any operation in the database.
+
+## Built-in Augmentations
+
+> **Note**: This document shows both available and planned augmentations. Each section is marked with its current status.
+
+### 1. Entity Registry Augmentation ✅ Available
+
+High-performance deduplication for streaming data ingestion.
+
+```typescript
+import { EntityRegistryAugmentation } from 'brainy'
+
+const brain = new Brainy({
+  augmentations: [
+    new EntityRegistryAugmentation({
+      maxCacheSize: 100000,      // Track up to 100k unique entities
+      ttl: 3600000,              // 1-hour TTL for cache entries
+      hashFields: ['id', 'url']  // Fields to use for deduplication
+    })
+  ]
+})
+
+// Automatically prevents duplicate entities
+await brain.add("Same content", { id: "123" }) // Added
+await brain.add("Same content", { id: "123" }) // Skipped (duplicate)
+```
+
+**Benefits:**
+- O(1) duplicate detection using bloom filters
+- Configurable cache size and TTL
+- Custom hash field selection
+- Perfect for real-time data streams
+
+
+Enterprise-grade durability and crash recovery.
+
+```typescript
+
+const brain = new Brainy({
+  augmentations: [
+      checkpointInterval: 1000,  // Checkpoint every 1000 operations
+      compression: true,          // Enable log compression
+      maxLogSize: 100 * 1024 * 1024  // 100MB max log size
+    })
+  ]
+})
+
+// All operations are now durably logged
+
+// Recover from crash
+const recovered = new Brainy({ 
+})
+```
+
+**Features:**
+- ACID compliance
+- Automatic crash recovery
+- Point-in-time recovery
+- Log compression and rotation
+- Minimal performance impact
+
+### 3. Intelligent Verb Scoring Augmentation ✅ Available
+
+AI-powered relationship strength calculation.
+
+```typescript
+import { IntelligentVerbScoringAugmentation } from 'brainy'
+
+const brain = new Brainy({
+  augmentations: [
+    new IntelligentVerbScoringAugmentation({
+      factors: {
+        semantic: 0.4,    // Weight for semantic similarity
+        temporal: 0.3,    // Weight for time proximity
+        frequency: 0.2,   // Weight for interaction frequency
+        explicit: 0.1     // Weight for explicit ratings
+      }
+    })
+  ]
+})
+
+// Relationships automatically get intelligent scores
+await brain.relate(user1, product1, "viewed", { timestamp: Date.now() })
+await brain.relate(user1, product1, "purchased", { timestamp: Date.now() })
+// Automatically calculates relationship strength based on multiple factors
+
+// Query using intelligent scores
+const strongRelationships = await brain.find({
+  connected: {
+    from: user1,
+    minScore: 0.8  // Only highly relevant relationships
+  }
+})
+```
+
+**Capabilities:**
+- Multi-factor relationship scoring
+- Temporal decay functions
+- Semantic similarity integration
+- Customizable weight factors
+
+### 4. Auto-Register Entities Augmentation ⚠️ Basic Implementation
+
+Automatically extracts and registers entities from text.
+
+```typescript
+import { AutoRegisterEntitiesAugmentation } from 'brainy'
+
+const brain = new Brainy({
+  augmentations: [
+    new AutoRegisterEntitiesAugmentation({
+      types: ['person', 'organization', 'location', 'product'],
+      confidence: 0.8,
+      createRelationships: true
+    })
+  ]
+})
+
+// Automatically extracts and registers entities
+await brain.add(
+  "Apple CEO Tim Cook announced the new iPhone 15 in Cupertino",
+  { type: "news" }
+)
+// Automatically creates:
+// - Noun: "Tim Cook" (person)
+// - Noun: "Apple" (organization)
+// - Noun: "iPhone 15" (product)
+// - Noun: "Cupertino" (location)
+// - Verbs: relationships between entities
+```
+
+**Features:**
+- NER (Named Entity Recognition)
+- Automatic relationship inference
+- Configurable entity types
+- Confidence thresholds
+
+### 5. Batch Processing Augmentation ✅ Available
+
+Optimizes bulk operations for maximum throughput.
+
+```typescript
+import { BatchProcessingAugmentation } from 'brainy'
+
+const brain = new Brainy({
+  augmentations: [
+    new BatchProcessingAugmentation({
+      batchSize: 100,
+      flushInterval: 1000,  // Flush every second
+      parallel: true,        // Parallel processing
+      maxQueueSize: 10000
+    })
+  ]
+})
+
+// Operations are automatically batched
+for (let i = 0; i < 10000; i++) {
+  await brain.add(`Item ${i}`)  // Internally batched
+}
+// Processes in optimized batches of 100
+```
+
+**Benefits:**
+- 10-100x throughput improvement
+- Automatic batching
+- Configurable batch sizes
+- Memory-efficient queue management
+
+### 6. Caching Augmentation 🚧 Coming Soon
+
+Intelligent multi-level caching system.
+
+```typescript
+import { CachingAugmentation } from 'brainy'
+
+const brain = new Brainy({
+  augmentations: [
+    new CachingAugmentation({
+      levels: {
+        l1: { size: 100, ttl: 60000 },      // Hot cache: 100 items, 1 min
+        l2: { size: 1000, ttl: 300000 },    // Warm cache: 1000 items, 5 min
+        l3: { size: 10000, ttl: 3600000 }   // Cold cache: 10k items, 1 hour
+      },
+      strategies: ['lru', 'lfu'],  // Least Recently/Frequently Used
+      preload: true                 // Preload popular items
+    })
+  ]
+})
+
+// Queries automatically use cache
+const results = await brain.find("popular query")  // Cached
+const again = await brain.find("popular query")    // From cache (instant)
+```
+
+**Features:**
+- Multi-level cache hierarchy
+- Multiple eviction strategies
+- Query result caching
+- Embedding cache
+- Automatic cache invalidation
+
+### 7. Compression Augmentation 🚧 Coming Soon
+
+Reduces storage size while maintaining query performance.
+
+```typescript
+import { CompressionAugmentation } from 'brainy'
+
+const brain = new Brainy({
+  augmentations: [
+    new CompressionAugmentation({
+      algorithm: 'brotli',
+      level: 6,  // Compression level (1-11)
+      threshold: 1024,  // Only compress items > 1KB
+      excludeFields: ['id', 'type']  // Don't compress these
+    })
+  ]
+})
+
+// Data automatically compressed/decompressed
+await brain.add(largeDocument)  // Compressed before storage
+const doc = await brain.getNoun(id)  // Decompressed on retrieval
+```
+
+**Benefits:**
+- 60-80% storage reduction
+- Transparent compression
+- Selective field compression
+- Multiple algorithm support
+
+### 8. Monitoring Augmentation 🚧 Coming Soon
+
+Real-time performance monitoring and metrics.
+
+```typescript
+import { MonitoringAugmentation } from 'brainy'
+
+const brain = new Brainy({
+  augmentations: [
+    new MonitoringAugmentation({
+      metrics: ['operations', 'latency', 'cache', 'memory'],
+      interval: 5000,  // Report every 5 seconds
+      webhook: 'https://metrics.example.com/brainy',
+      console: true  // Also log to console
+    })
+  ]
+})
+
+// Automatic metric collection
+brain.on('metrics', (metrics) => {
+  console.log(`
+    Operations/sec: ${metrics.opsPerSecond}
+    Avg latency: ${metrics.avgLatency}ms
+    Cache hit rate: ${metrics.cacheHitRate}%
+    Memory usage: ${metrics.memoryMB}MB
+  `)
+})
+```
+
+**Metrics:**
+- Operation throughput
+- Query latency percentiles
+- Cache hit rates
+- Memory usage
+- Storage growth
+- Error rates
+
+## Neural Import Capabilities 🚧 Coming Soon
+
+> **Note**: Import/Export features are currently in development. Expected Q1 2025.
+
+### 1. Document Import with Auto-Structuring
+
+```typescript
+import { NeuralImportAugmentation } from 'brainy'
+
+const brain = new Brainy({
+  augmentations: [
+    new NeuralImportAugmentation({
+      autoStructure: true,
+      extractEntities: true,
+      generateSummaries: true,
+      detectLanguage: true
+    })
+  ]
+})
+
+// Import unstructured documents
+await brain.importDocument('./research-paper.pdf')
+// Automatically:
+// - Extracts text and metadata
+// - Identifies sections and structure
+// - Extracts entities and concepts
+// - Generates embeddings per section
+// - Creates relationship graph
+```
+
+### 2. Database Migration Import
+
+```typescript
+// Import from existing databases
+await brain.importFromSQL({
+  connection: 'postgres://localhost/mydb',
+  tables: {
+    users: { type: 'person', idField: 'user_id' },
+    products: { type: 'product', idField: 'sku' },
+    orders: { 
+      type: 'relationship',
+      from: 'user_id',
+      to: 'product_id',
+      verb: 'purchased'
+    }
+  }
+})
+
+// Import from MongoDB
+await brain.importFromMongo({
+  uri: 'mongodb://localhost:27017',
+  database: 'myapp',
+  collections: {
+    users: { type: 'person' },
+    posts: { type: 'content' }
+  }
+})
+```
+
+### 3. Stream Import
+
+```typescript
+// Import from real-time streams
+await brain.importStream({
+  source: 'kafka://localhost:9092/events',
+  format: 'json',
+  transform: (event) => ({
+    noun: event.data,
+    metadata: {
+      type: event.type,
+      timestamp: event.timestamp
+    }
+  }),
+  deduplication: true
+})
+```
+
+### 4. Bulk CSV/JSON Import
+
+```typescript
+// Import CSV with automatic type detection
+await brain.importCSV('./data.csv', {
+  headers: true,
+  typeColumn: 'entity_type',
+  detectRelationships: true,
+  batchSize: 1000
+})
+
+// Import JSON with nested structure handling
+await brain.importJSON('./data.json', {
+  rootPath: '$.entities',
+  nounPath: '$.content',
+  metadataPath: '$.properties',
+  relationshipPath: '$.connections'
+})
+```
+
+## Creating Custom Augmentations
+
+```typescript
+import { Augmentation } from 'brainy'
+
+class CustomAugmentation extends Augmentation {
+  name = 'CustomAugmentation'
+  
+  async onInit(brain: Brainy): Promise<void> {
+    // Initialize augmentation
+    console.log('Custom augmentation initialized')
+  }
+  
+  async onBeforeAddNoun(content: any, metadata: any): Promise<[any, any]> {
+    // Modify before adding noun
+    metadata.processed = true
+    metadata.timestamp = Date.now()
+    return [content, metadata]
+  }
+  
+  async onAfterAddNoun(id: string, noun: any): Promise<void> {
+    // React to noun addition
+    console.log(`Noun ${id} added`)
+  }
+  
+  async onBeforeSearch(query: any): Promise<any> {
+    // Modify search query
+    query.boost = 'recent'
+    return query
+  }
+  
+  async onAfterSearch(results: any[]): Promise<any[]> {
+    // Process search results
+    return results.map(r => ({
+      ...r,
+      customScore: r.score * 1.5
+    }))
+  }
+}
+
+// Use custom augmentation
+const brain = new Brainy({
+  augmentations: [new CustomAugmentation()]
+})
+```
+
+## Augmentation Lifecycle Hooks
+
+### Available Hooks
+
+```typescript
+interface AugmentationHooks {
+  // Initialization
+  onInit(brain: Brainy): Promise<void>
+  onShutdown(): Promise<void>
+  
+  // Noun operations
+  onBeforeAddNoun(content, metadata): Promise<[content, metadata]>
+  onAfterAddNoun(id, noun): Promise<void>
+  onBeforeGetNoun(id): Promise<string>
+  onAfterGetNoun(noun): Promise<any>
+  onBeforeUpdateNoun(id, updates): Promise<[string, any]>
+  onAfterUpdateNoun(id, noun): Promise<void>
+  onBeforeDeleteNoun(id): Promise<string>
+  onAfterDeleteNoun(id): Promise<void>
+  
+  // Verb operations
+  onBeforeAddVerb(source, target, type, metadata): Promise<[any, any, string, any]>
+  onAfterAddVerb(id, verb): Promise<void>
+  onBeforeGetVerb(id): Promise<string>
+  onAfterGetVerb(verb): Promise<any>
+  
+  // Search operations
+  onBeforeSearch(query): Promise<any>
+  onAfterSearch(results): Promise<any[]>
+  onBeforeFind(query): Promise<any>
+  onAfterFind(results): Promise<any[]>
+  
+  // Storage operations
+  onBeforeSave(data): Promise<any>
+  onAfterLoad(data): Promise<any>
+  
+  // Events
+  onError(error): Promise<void>
+  onMetric(metric): Promise<void>
+}
+```
+
+## Augmentation Composition
+
+```typescript
+// Combine multiple augmentations
+const brain = new Brainy({
+  augmentations: [
+    // Order matters - executed in sequence
+    new EntityRegistryAugmentation(),    // Deduplication first
+    new AutoRegisterEntitiesAugmentation(), // Entity extraction
+    new IntelligentVerbScoringAugmentation(), // Scoring
+    new CompressionAugmentation(),       // Compression
+    new CachingAugmentation(),          // Caching
+    new MonitoringAugmentation()        // Monitoring last
+  ]
+})
+```
+
+## Performance Considerations
+
+1. **Order Matters**: Place filtering augmentations early
+2. **Resource Usage**: Monitor memory with many augmentations
+3. **Async Operations**: Use parallel processing where possible
+4. **Caching**: Enable caching augmentation for read-heavy workloads
+
+## Best Practices
+
+1. **Single Responsibility**: Each augmentation should do one thing well
+2. **Non-Blocking**: Avoid blocking operations in hooks
+3. **Error Handling**: Always handle errors gracefully
+4. **Configuration**: Make augmentations configurable
+5. **Documentation**: Document augmentation behavior and options
+
+## See Also
+
+- [Architecture Overview](./overview.md)
+- [API Reference](../api/README.md)
+- [Performance Guide](../guides/performance.md)

docs/architecture/data-storage-architecture.md

@@ -0,0 +1,388 @@
+# Brainy Data Storage Architecture (8.0)
+
+**Complete on-disk reference for the 8.0 layout.**
+
+This document describes what a Brainy 8.0 data directory actually contains: the
+canonical entity records, the system area, the generational-MVCC bookkeeping,
+the column store, the blob area, and the lock files — plus how the in-memory
+indexes rebuild from them. The authoritative design records are
+[ADR-001 (generational MVCC)](../ADR-001-generational-mvcc.md) and
+[index-architecture.md](./index-architecture.md); this document is the on-disk
+map that ties them together.
+
+8.0 removed the 7.x copy-on-write subsystem (`_cow/`, `branches/{branch}/…`
+paths) and the cloud/OPFS storage adapters. The two storage backends are
+**filesystem** and **memory**; both speak the same path vocabulary (memory
+storage keys its internal map by the identical path strings).
+
+---
+
+## 1. Directory Tree
+
+A real 8.0 filesystem store (`path`, default `./brainy-data`):
+
+```
+brainy-data/
+│
+├── entities/                            # Canonical records (current state)
+│   ├── nouns/
+│   │   └── {shard}/                     # 256 shards: first 2 hex chars of the UUID
+│   │       └── {id}/                    # One directory per entity UUID
+│   │           ├── vectors.json.gz      # Embedding + HNSW node state
+│   │           └── metadata.json.gz     # Everything else (type, subtype, data, fields, _rev)
+│   └── verbs/
+│       └── {shard}/
+│           └── {id}/
+│               ├── vectors.json.gz      # Relationship embedding (when present)
+│               └── metadata.json.gz     # sourceId, targetId, verb, subtype, weight, data…
+│
+├── _system/                             # System singletons + bucketed system keys
+│   ├── generation.json(.gz)             # { generation, updatedAt } — the write watermark
+│   ├── manifest.json                    # { version, generation, … } — MVCC commit point
+│   ├── tx-log.jsonl                     # One line per committed transact() batch (append-only)
+│   ├── counts.json                      # Entity/verb totals
+│   ├── type-statistics.json.gz          # Per-NounType counts
+│   ├── subtype-statistics.json.gz       # Per-(NounType, subtype) counts
+│   ├── verb-subtype-statistics.json.gz  # Per-(VerbType, subtype) counts
+│   ├── statistics.json                  # Aggregate statistics blob (counts, index sizes)
+│   ├── hnsw-system.json                 # Vector-index entry point + max level
+│   ├── __metadata_field_registry__.json.gz   # Which metadata fields are indexed
+│   ├── brainy:entityIdMapper.json.gz    # UUID ↔ u64 mapping for native index providers
+│   └── idx/
+│       └── {bucket}/                    # 256 buckets: FNV-1a hash of the key
+│           ├── __metadata_field_index__field_{name}.json.gz   # Sparse field indexes
+│           ├── __chunk__*.json.gz       # Metadata-index roaring-bitmap chunks
+│           ├── __sparse_index__*.json.gz# Zone maps + bloom filters
+│           └── graph-lsm-verbs-{source|target}-*.json.gz      # Graph LSM SSTables + manifest
+│
+├── _generations/                        # MVCC history (written ONLY by transact())
+│   └── {N}/                             # One directory per committed generation N
+│       ├── tx.json                      # The generation-N delta (immutable)
+│       └── prev/
+│           └── {id}.json                # Before-image of each touched record (immutable)
+│
+├── _column_index/                       # Column store manifests (one dir per field)
+│   └── {field}/
+│       └── MANIFEST.json.gz             # Run list + zone metadata for that column
+│
+├── _blobs/                              # Binary blob area (`<key>.bin` convention)
+│   ├── _column_index/
+│   │   └── {field}/
+│   │       └── L0-000001.bin            # Column-store runs (level-0 segments)
+│   └── …                                # VFS file content and other binary blobs
+│
+└── locks/                               # Process coordination (NEVER snapshotted)
+    ├── _writer.lock                     # Single-writer lock: pid, hostname, heartbeat
+    ├── _flush_requests/                 # Reader→writer flush RPC (.req files)
+    └── _flush_responses/                # Writer acks (.ack files)
+```
+
+Most JSON objects are gzip-compressed (`.json.gz`) — compression is on by
+default for filesystem storage (`storage.options.compression`, zlib level 6).
+A few hot singletons (`manifest.json`, `counts.json`, `hnsw-system.json`,
+`tx-log.jsonl`) are written uncompressed for cheap partial reads and appends.
+
+---
+
+## 2. Canonical Entity Records
+
+Each entity (noun) and relationship (verb) is **two files** under one
+ID-first directory. The split keeps vector I/O (large, append-mostly) separate
+from metadata I/O (small, read-heavy).
+
+### Noun vector file — `entities/nouns/{shard}/{id}/vectors.json.gz`
+
+```json
+{
+  "id": "421d92e7-4241-470a-80f4-4b39414e7a83",
+  "vector": [-0.139, -0.056, 0.028, "…384 dims…"],
+  "connections": { "0": ["neighbor-uuid…"] },
+  "level": 0
+}
+```
+
+The HNSW node state (`connections`, `level`) is persisted with the vector so
+the vector index can rebuild without recomputing the graph.
+
+### Noun metadata file — `entities/nouns/{shard}/{id}/metadata.json.gz`
+
+```json
+{
+  "data": "React is a JavaScript library for building user interfaces",
+  "noun": "concept",
+  "subtype": "cli-add",
+  "createdAt": 1781198053726,
+  "updatedAt": 1781198053726,
+  "_rev": 1
+}
+```
+
+- `noun` is the NounType. **Type lives in metadata, not in the path** — lookup
+  by ID is a single path construction, no type needed.
+- `subtype` is the per-product sub-classification (required on write by
+  default in 8.0).
+- `_rev` increments on every write and backs `update({ ifRev })` CAS.
+- Consumer metadata fields sit alongside the standard ones.
+
+### Verb files — `entities/verbs/{shard}/{id}/…`
+
+Same two-file split. The verb metadata record carries the graph edge:
+`sourceId`, `targetId`, `verb` (VerbType), `subtype`, `weight`, `data`,
+`metadata`, timestamps, `_rev`. Verb IDs are Brainy-generated UUIDs by
+contract (8.0 rejects caller-supplied verb ids) because native graph providers
+intern the raw UUID bytes as u64 handles.
+
+### Path construction
+
+```typescript
+const shard = id.substring(0, 2)                                  // '42'
+const metadataPath = `entities/nouns/${shard}/${id}/metadata.json`
+const vectorsPath  = `entities/nouns/${shard}/${id}/vectors.json`
+// Verbs: same shape under entities/verbs/
+```
+
+Implemented in `src/storage/baseStorage.ts` (path generators) and
+`src/storage/sharding.ts` (`getShardIdFromUuid`).
+
+---
+
+## 3. The `_system/` Area
+
+Two kinds of keys live here, resolved by `BaseStorage.parsePath()`:
+
+1. **Singletons** — well-known keys written at `_system/<key>.json`:
+   `counts`, `statistics`, `type-statistics`, `hnsw-system`,
+   `__metadata_field_registry__`, `brainy:entityIdMapper`, plus the MVCC
+   trio (`generation.json`, `manifest.json`, `tx-log.jsonl`).
+2. **Bucketed system keys** — everything else (field indexes, bitmap chunks,
+   sparse-index segments, graph LSM SSTables) hashes into one of 256
+   `_system/idx/{bucket}/` directories via FNV-1a, so no single directory
+   accumulates unbounded entries.
+
+Notable singletons:
+
+| File | Contents |
+|------|----------|
+| `generation.json` | `{ generation, updatedAt }` — monotonic watermark, bumped by **every** write batch |
+| `manifest.json` | MVCC commit point: highest *committed* generation (see §4) |
+| `tx-log.jsonl` | One JSON line per committed `transact()` batch: generation, timestamp, `meta` |
+| `type-statistics.json.gz` | Per-NounType counts (backs `brain.counts.byType`) |
+| `subtype-statistics.json.gz` | `{ counts: { [type]: { [subtype]: n } }, updatedAt }` (contract-bound shape) |
+| `verb-subtype-statistics.json.gz` | Same shape for VerbTypes |
+| `hnsw-system.json` | `{ entryPointId, maxLevel }` — per-node state lives in each entity's `vectors.json` |
+| `brainy:entityIdMapper.json.gz` | UUID ↔ u64 interning table for the BigInt provider contract |
+| `__metadata_field_registry__.json.gz` | Registry of indexed metadata field names |
+
+---
+
+## 4. Generational MVCC (`_generations/` + the `_system` trio)
+
+Full design in [ADR-001](../ADR-001-generational-mvcc.md). The on-disk shape:
+
+```
+_system/generation.json      { generation, updatedAt }          atomic tmp+rename
+_system/manifest.json        { version, generation, … }         atomic tmp+rename — THE commit point
+_system/tx-log.jsonl         one line per committed transact()  append-only
+_generations/{N}/tx.json     the generation-N delta             immutable once written
+_generations/{N}/prev/{id}.json   before-image of {id}          immutable once written
+```
+
+Commit protocol (writer side): stage before-images and the delta under
+`_generations/N/`, fsync, apply the delta to the canonical `entities/…`
+records, then atomically rename `manifest.json` to publish generation N. The
+tx-log line is appended last (advisory). Crash recovery on open discards any
+`_generations/{N}` newer than the manifest.
+
+Two write classes share the generation clock:
+
+- **Single-operation writes** (`add`/`update`/`remove`/`relate` outside
+  `transact()`) bump `generation.json` so watermarks and `_rev` CAS stay sound,
+  but write **no** history — they are not visible to `db.since()` and remain
+  visible through earlier pins.
+- **`transact()` batches** write the full `_generations/{N}` record and a
+  tx-log line, and are the unit of time travel (`brain.asOf()`).
+
+Snapshots (`db.persist(path)`) hard-link the entire store **except `locks/`**
+into a self-contained directory openable via `Brainy.load(path)`.
+
+---
+
+## 5. Column Store (`_column_index/` + `_blobs/_column_index/`)
+
+The metadata index persists per-field columnar runs for O(log n) range and
+membership queries at scale:
+
+- `_column_index/{field}/MANIFEST.json.gz` — the run list and zone metadata
+  for one field (`createdAt`, `subtype`, `noun`, `_rev`, consumer fields,
+  `__words__` for tokenized text…).
+- `_blobs/_column_index/{field}/L0-NNNNNN.bin` — the actual level-0 run
+  segments, stored through the shared `_blobs/<key>.bin` binary convention.
+
+Sparse per-field indexes, roaring-bitmap chunks, and zone-map/bloom segments
+additionally live as bucketed keys under `_system/idx/` (see §3). Which path
+serves a given `where` clause is the query planner's decision — inspect it
+with `brainy inspect explain <dir> --where '…'`.
+
+---
+
+## 6. Blob Area (`_blobs/`)
+
+`_blobs/<key>.bin` is the flat binary-blob convention shared by every storage
+adapter (`saveBinaryBlob`/`getBinaryBlob` in the storage contract):
+
+- **VFS file content** — VFS entities are regular nouns (path, ownership, and
+  timestamps in entity metadata); the file *bytes* are blobs.
+- **Column-store runs** (under the `_column_index/` key prefix, §5).
+- Any other binary payload an index provider persists.
+
+Writes use unique temp names + rename, so concurrent writers of the same key
+cannot tear each other's blobs.
+
+---
+
+## 7. Locks (`locks/`)
+
+```
+locks/_writer.lock          # single-writer lock: { pid, hostname, startedAt, heartbeat, version }
+locks/_flush_requests/      # readers drop <uuid>.req to ask the writer to flush
+locks/_flush_responses/     # writer answers with <uuid>.ack
+```
+
+- One **writer** per data directory, enforced at `init()`; stale locks (dead
+  PID / stale heartbeat) are reclaimed automatically.
+- Read-only processes (`Brainy.openReadOnly()`, the `brainy inspect` CLI
+  family) can ask the live writer to flush via the request/response files, so
+  out-of-process diagnostics see fresh state.
+- `locks/` is excluded from snapshots (`SNAPSHOT_EXCLUDED_TOP_DIRS` in
+  `src/storage/adapters/fileSystemStorage.ts`).
+
+---
+
+## 8. In-Memory Indexes and What Rebuilds From What
+
+| Index | In memory | Persisted state | Rebuild source |
+|-------|-----------|-----------------|----------------|
+| **Vector (HNSW)** | Graph of vector connections | `_system/hnsw-system.json` + per-entity `vectors.json` | Walk entity vector files; lazy mode loads structure only and pages vectors on demand |
+| **Metadata index** | Field → value bitmaps + column-store readers | `_system/idx/` chunks + `_column_index/` manifests + `_blobs/_column_index/` runs | Loaded directly; full rebuild re-scans entity metadata |
+| **Graph adjacency** | sourceId/targetId → verb-id LSM trees | `graph-lsm-verbs-{source,target}-*` SSTables under `_system/idx/` | Loaded from SSTables; full rebuild re-scans verb metadata |
+| **Counts/statistics** | Per-type and per-subtype maps | `_system/{type,subtype,verb-subtype}-statistics.json.gz`, `counts.json` | Recomputable by scanning entities (`brainy inspect repair`) |
+
+A pluggable index provider (the 8.0 plugin contract in
+`@soulcraft/brainy/plugin`) may replace any of the JS implementations; the
+persisted formats above are contract-bound so JS and native implementations
+can interleave on the same directory.
+
+---
+
+## 9. Sharding Strategy
+
+**Entities:** first 2 hex characters of the UUID → 256 uniform shards.
+Deterministic, configuration-free, and keeps per-directory entry counts low
+(at 1M entities: ~3,900 directories per shard). Paginated whole-store walks
+(`getNouns`/`getVerbs`) iterate shards `00`–`ff` in order.
+
+**System keys:** FNV-1a hash of the key → 256 `_system/idx/` buckets. Same
+motivation, different keyspace (system keys are not UUIDs).
+
+**What is never sharded:** the `_system/` singletons, `_generations/{N}`
+directories (keyed by generation number), `_column_index/{field}` manifests
+(keyed by field name), and `locks/`.
+
+---
+
+## 10. Durability and Atomicity
+
+- **Per-object atomicity:** every JSON object and blob is written to a unique
+  temp file then `rename()`d — readers never observe torn objects.
+- **Transaction atomicity:** the `manifest.json` rename is the single commit
+  point for `transact()` batches (§4); everything staged before it is
+  discarded by crash recovery if the rename never lands.
+- **Compression:** gzip per object (`.json.gz`), transparent to all readers.
+  Native index providers that mmap binary formats use the uncompressed
+  `_blobs/` area instead.
+
+---
+
+## 11. `clear()` Semantics
+
+`brain.clear()` removes all entities, relationships, indexes, statistics, and
+MVCC history, then re-resolves every index exactly as `init()` does —
+including plugin-provided vector/metadata/id-mapper factories and VFS root
+re-creation. The data directory afterwards contains a fresh, empty store (the
+writer lock remains held by the running process).
+
+---
+
+## 12. Common Scenarios
+
+### Adding an entity
+
+```
+brain.add({ data, type, subtype })
+1. Generate UUID → shard = first 2 hex chars
+2. Embed data → 384-dim vector
+3. Write entities/nouns/{shard}/{id}/vectors.json.gz   (vector + HNSW node state)
+4. Write entities/nouns/{shard}/{id}/metadata.json.gz  (type/subtype/data/fields, _rev: 1)
+5. Update in-memory indexes (HNSW insert, metadata index, statistics)
+6. Bump _system/generation.json (no _generations/ entry — single-op write)
+```
+
+### Committing a transaction
+
+```
+await brain.transact(tx => { tx.add(…); tx.update(…) })
+1. Stage _generations/{N}/prev/{id}.json before-images + tx.json delta; fsync
+2. Apply the delta to canonical entities/… records
+3. Atomic-rename _system/manifest.json → generation N is committed
+4. Append one line to _system/tx-log.jsonl
+```
+
+### Cold start
+
+```
+await brain.init()
+1. Acquire locks/_writer.lock (or open read-only)
+2. Crash recovery: drop _generations/{N} newer than manifest.json
+3. Load _system singletons (counts, statistics, field registry, id mapper)
+4. Vector index: hnsw-system.json + entity vectors.json (lazy mode if large)
+5. Graph adjacency: load LSM SSTables from _system/idx/
+6. Metadata index: column-store manifests + bitmap chunks on demand
+```
+
+### Snapshot and restore
+
+```
+const db = brain.now(); await db.persist('/backups/today'); await db.release()
+→ hard-links everything except locks/ into a self-contained directory
+
+await Brainy.load('/backups/today')        // open snapshot read-only as a Db
+await brain.restore('/backups/today', { confirm: true })   // replace store state
+```
+
+---
+
+## 13. Summary
+
+- **Two backends** (filesystem, memory), one path vocabulary.
+- **Two files per entity** under ID-first `entities/{kind}/{shard}/{id}/`.
+- **Type and subtype are metadata**, not directory structure; type queries go
+  through the metadata index, not the filesystem.
+- **`_system/`** holds singletons plus 256 hash buckets of index state.
+- **`_generations/` + `manifest.json` + `tx-log.jsonl`** implement
+  generational MVCC. History is per-write: every `add()`/`update()`/`remove()`/
+  `relate()` gets its own generation, and `transact()` groups several ops into
+  one atomic generation. (Single-op retention has been the model since 8.0;
+  you never need to route a write through `transact()` just to keep its history.)
+- **`_column_index/` + `_blobs/`** hold the columnar metadata runs and binary
+  blobs (VFS content included).
+- **`locks/`** coordinates the single writer and reader flush requests, and
+  never travels with snapshots.
+
+---
+
+## Next Steps
+
+- [ADR-001 — Generational MVCC](../ADR-001-generational-mvcc.md)
+- [Index Architecture](./index-architecture.md)
+- [Consistency Model](../concepts/consistency-model.md)
+- [VFS Guide](../vfs/README.md)

docs/architecture/finite-type-system.md

@@ -0,0 +1,538 @@
+# 🎯 Brainy's Finite Noun/Verb Type System
+
+> **Why Brainy's Finite Type System is Revolutionary for Knowledge Graphs at Billion Scale**
+
+## Overview
+
+Brainy introduces a **finite type system** that sits between traditional schemaless NoSQL and rigid relational databases. This approach unlocks unprecedented optimization opportunities while maintaining semantic flexibility.
+
+---
+
+## The Three-Way Comparison
+
+### 1. Traditional NoSQL (Schemaless)
+
+```typescript
+// Complete freedom, zero optimization
+{
+  id: '123',
+  randomField1: 'value',
+  anotherWeirdKey: 42,
+  whoKnowsWhatElse: { nested: 'chaos' }
+}
+```
+
+**Problems:**
+- ❌ No index optimization possible
+- ❌ Tools can't understand data structure
+- ❌ Incompatible augmentations/extensions
+- ❌ Memory explosion with billions of unique keys
+- ❌ No semantic understanding
+- ❌ Query planning impossible
+
+### 2. Traditional Relational (Rigid Schema)
+
+```sql
+CREATE TABLE entities (
+  id UUID PRIMARY KEY,
+  field1 VARCHAR(255),
+  field2 INTEGER,
+  ...
+  field50 TEXT
+);
+```
+
+**Problems:**
+- ❌ Must define schema upfront
+- ❌ Schema migrations are painful
+- ❌ Can't handle heterogeneous data
+- ❌ Requires restart for schema changes
+- ❌ Fixed columns waste space
+
+### 3. Brainy's Finite Type System (Semantic Structure)
+
+```typescript
+// Finite noun types (extensible but constrained)
+type NounType =
+  | 'person' | 'place' | 'organization' | 'document'
+  | 'event' | 'concept' | 'thing' | ...
+
+// Finite verb types (semantic relationships)
+type VerbType =
+  | 'relatedTo' | 'contains' | 'isA' | 'causedBy'
+  | 'precedes' | 'influences' | ...
+
+// Example usage
+const entity = {
+  id: '123',
+  nounType: 'person',        // Finite! Known type
+  vector: [...],             // Semantic embedding
+  metadata: {
+    noun: 'person',          // Required type field
+    name: 'Alice',           // Custom fields allowed
+    occupation: 'Engineer'   // Flexible metadata
+  }
+}
+```
+
+**Benefits:**
+- ✅ **Index Optimization**: Fixed-size Uint32Arrays for type tracking (99.76% memory reduction)
+- ✅ **Semantic Understanding**: Types have meaning, not just structure
+- ✅ **Tool Compatibility**: All augmentations understand core types
+- ✅ **Concept Extraction**: NLP can map text to known types
+- ✅ **Explicit Types**: Clear type specification in API
+- ✅ **Query Optimization**: Type-aware query planning
+- ✅ **Flexible Metadata**: Any fields within typed structure
+- ✅ **Billion-Scale Ready**: Type tracking scales linearly
+
+---
+
+## Revolutionary Benefits in Detail
+
+### 1. Index Optimization at Billion Scale
+
+**The Problem**: Traditional NoSQL stores arbitrary field names in indexes:
+
+```typescript
+// Memory explosion with unique keys
+Map<string, Set<string>> {
+  "user_preference_notification_email_enabled": Set(['id1', 'id2', ...]),
+  "customer_shipping_address_line_1": Set(['id3', 'id4', ...]),
+  // Billions of unique, unpredictable keys!
+}
+```
+
+**Brainy's Solution**: Fixed noun/verb types enable fixed-size tracking:
+
+```typescript
+// 99.76% memory reduction with Uint32Arrays
+class TypeAwareMetadataIndex {
+  // Fixed size: nounTypes × verbTypes × fieldCount
+  private nounTypeBitmaps: RoaringBitmap32[]        // One per noun type
+  private verbTypeBitmaps: RoaringBitmap32[]        // One per verb type
+
+  // Example: 100 noun types × 50 verb types = 5KB overhead
+  // vs 500MB+ for arbitrary keys!
+}
+```
+
+**Real-World Impact (PROJECTED - not yet benchmarked)**:
+- **Before**: 500MB memory for 1M entities with diverse keys
+- **After**: PROJECTED 1.2MB memory for same dataset (385x reduction - calculated from Uint32Array size, not measured)
+- **Scales to billions**: Memory grows with entity count, not key diversity
+
+### 2. Explicit Type System
+
+**The Design**: Specify types clearly in your API calls:
+
+```typescript
+import { Brainy, NounType, VerbType } from '@soulcraft/brainy'
+
+// Add entity with explicit type
+await brain.add({
+  data: { name: 'Alice', role: 'CEO of Acme Corp' },
+  type: NounType.Person  // Explicit type specification
+})
+
+// Query with type filtering
+await brain.find({
+  query: 'Alice',
+  type: NounType.Person  // Type-optimized search
+})
+```
+
+**Why Explicit Types?**:
+1. **Deterministic**: You control exactly how entities are classified
+2. **Predictable**: No inference surprises or edge cases
+3. **Fast**: No neural processing overhead on every add/query
+4. **Smaller**: No embedded keyword models needed
+
+**Real-World Use Case**:
+```typescript
+// Import data with known types
+await brain.add({
+  data: { name: 'Apple Inc.', industry: 'Technology' },
+  type: NounType.Organization
+})
+
+await brain.add({
+  data: { name: 'Cupertino', country: 'USA' },
+  type: NounType.Location
+})
+
+// Create relationship
+await brain.relate({
+  from: appleId,
+  to: cupertinoId,
+  type: VerbType.LocatedIn
+})
+```
+
+### 3. Tool & Augmentation Compatibility
+
+**The Problem with Schemaless**: Every tool must handle infinite variations:
+
+```typescript
+// Incompatible tools
+const tool1Data = { type: 'person', name: 'Alice' }
+const tool2Data = { kind: 'human', fullName: 'Alice' }
+const tool3Data = { entity_type: 'individual', person_name: 'Alice' }
+
+// Tools can't understand each other!
+```
+
+**Brainy's Solution**: Finite types create a common language:
+
+```typescript
+// All tools/augmentations understand core types
+interface NounMetadata {
+  noun: NounType  // Agreed-upon type system
+  // ... custom fields
+}
+
+// Augmentation 1: Adds caching for 'person' entities
+class PersonCacheAugmentation {
+  execute(op, params) {
+    if (params.noun?.metadata?.noun === 'person') {
+      // All person entities are understood!
+    }
+  }
+}
+
+// Augmentation 2: Enriches 'organization' entities
+class OrgEnrichmentAugmentation {
+  execute(op, params) {
+    if (params.noun?.metadata?.noun === 'organization') {
+      // Fetch industry data, employees, etc.
+    }
+  }
+}
+
+// Augmentations compose seamlessly!
+```
+
+**Ecosystem Benefits**:
+- Third-party augmentations are **interoperable**
+- Type-specific optimizations are **portable**
+- Query builders understand **semantic structure**
+- Visualization tools render **type-appropriate** displays
+- Import/export tools map to **universal types**
+
+### 4. Concept Extraction & NLP Integration
+
+**Traditional Approach**: Extract entities, ignore types:
+
+```typescript
+// Generic NER (Named Entity Recognition)
+"Alice works at Google"
+// → ['Alice', 'Google']  // What are these?
+```
+
+**Brainy's Approach**: Extract **typed** concepts:
+
+```typescript
+import { NaturalLanguageProcessor } from '@soulcraft/brainy'
+
+const nlp = new NaturalLanguageProcessor()
+const concepts = await nlp.extractConcepts("Alice works at Google in San Francisco")
+
+// Returns typed entities:
+[
+  { text: 'Alice', nounType: 'person', confidence: 0.95 },
+  { text: 'Google', nounType: 'organization', confidence: 0.98 },
+  { text: 'San Francisco', nounType: 'place', confidence: 0.92 }
+]
+
+// And typed relationships:
+[
+  {
+    from: 'Alice',
+    to: 'Google',
+    verbType: 'worksAt',
+    confidence: 0.88
+  },
+  {
+    from: 'Google',
+    to: 'San Francisco',
+    verbType: 'locatedIn',
+    confidence: 0.85
+  }
+]
+```
+
+**Downstream Benefits**:
+- **Smart Clustering**: Group by semantic type, not arbitrary keys
+- **Type-Aware Queries**: "Find all organizations in California"
+- **Relationship Reasoning**: "Who works at companies in SF?"
+- **Automatic Ontology**: Types form natural hierarchy
+
+### 5. Query Optimization & Planning
+
+**The Problem**: Schemaless queries are guesswork:
+
+```sql
+-- MongoDB: No idea what fields exist
+db.collection.find({ someField: 'value' })
+// Full collection scan!
+```
+
+**Brainy's Solution**: Type-aware query planning:
+
+```typescript
+// Query planner knows types exist!
+brain.find({
+  where: { noun: 'person' }  // Type index lookup: O(1)!
+})
+
+// Multi-type queries are optimized
+brain.find({
+  where: {
+    noun: ['person', 'organization'],  // Bitmap union
+    location: 'California'              // Then filter
+  }
+})
+
+// Relationship traversal is type-aware
+brain.find({
+  verb: 'worksAt',          // Verb type index
+  sourceType: 'person',     // Source noun type index
+  targetType: 'organization' // Target noun type index
+})
+```
+
+**Query Performance**:
+- **Type Filtering**: O(1) bitmap intersection
+- **Join Planning**: Type-aware join order optimization
+- **Index Selection**: Automatic best index for type
+- **Cardinality Estimation**: Type statistics guide planning
+
+### 6. Architecture & Development Benefits
+
+#### Memory-Efficient Type Tracking
+
+```typescript
+// Traditional approach: Map per field
+class TraditionalIndex {
+  private fieldIndexes: Map<string, Map<any, Set<string>>>
+  // Memory: O(unique_fields × unique_values × entities)
+}
+
+// Brainy approach: Fixed Uint32Array per type
+class TypeAwareIndex {
+  private nounTypeTracking: Uint32Array  // Fixed size!
+  private typeIndexes: RoaringBitmap32[] // One per type
+  // Memory: O(noun_types) + O(entities_per_type)
+  // PROJECTED: 385x smaller at billion scale (calculated from architecture, not benchmarked)
+}
+```
+
+#### Type-Driven Code Organization
+
+```typescript
+// Natural code structure follows types
+/src
+  /nouns
+    /person
+      personStorage.ts       // Type-specific storage
+      personQueries.ts       // Type-specific queries
+      personAugmentation.ts  // Type-specific logic
+    /organization
+      orgStorage.ts
+      orgQueries.ts
+      orgAugmentation.ts
+  /verbs
+    /worksAt
+      worksAtValidation.ts   // Relationship rules
+      worksAtInference.ts    // Type inference
+```
+
+#### Type Safety in TypeScript
+
+```typescript
+// Compiler-enforced type correctness
+function processPerson(noun: Noun) {
+  if (noun.metadata.noun === 'person') {
+    // TypeScript narrows type!
+    const name: string = noun.metadata.name  // Safe access
+  }
+}
+
+// Exhaustive type checking
+function processNoun(noun: Noun) {
+  switch (noun.metadata.noun) {
+    case 'person': return handlePerson(noun)
+    case 'place': return handlePlace(noun)
+    case 'organization': return handleOrg(noun)
+    // Compiler error if missing cases!
+  }
+}
+```
+
+---
+
+## Public API: Type System
+
+The type system is **fully public** for developers and augmentation authors:
+
+```typescript
+import {
+  NounType,
+  VerbType,
+  getNounTypes,
+  getVerbTypes,
+  BrainyTypes,
+  suggestType
+} from '@soulcraft/brainy'
+
+// Get all available noun types
+const nounTypes = getNounTypes()
+// → ['Person', 'Organization', 'Location', 'Thing', 'Concept', ...]
+
+// Get all available verb types
+const verbTypes = getVerbTypes()
+// → ['RelatedTo', 'Contains', 'CreatedBy', 'LocatedIn', ...]
+
+// Use types directly
+await brain.add({
+  data: { name: 'Alice' },
+  type: NounType.Person
+})
+
+// Query by type
+await brain.find({
+  type: NounType.Person,
+  where: { name: 'Alice' }
+})
+```
+
+**Use Cases**:
+- **Type-Safe Code**: Use TypeScript enums for compile-time checking
+- **Import Tools**: Specify entity types during data import
+- **Query Builders**: Filter by known types
+- **Augmentations**: Type-specific processing pipelines
+- **Visualization**: Type-appropriate rendering
+
+---
+
+## Real-World Performance Comparison
+
+### Scenario: 1 Billion Entities with Rich Metadata
+
+| Aspect | NoSQL (Schemaless) | Relational (Fixed) | Brainy (Finite Types) |
+|--------|-------------------|-------------------|----------------------|
+| **Memory (Indexes)** | 500GB+ | 250GB | 1.3GB |
+| **Type Lookup** | Full scan | O(log n) | O(1) bitmap |
+| **Add New Type** | Zero cost | Schema migration! | Register type |
+| **Query Planning** | Impossible | Table statistics | Type statistics |
+| **Tool Compatibility** | None | SQL only | Full ecosystem |
+| **Semantic Understanding** | None | None | Built-in |
+| **Concept Extraction** | Manual | Manual | Via SmartExtractor |
+| **Flexibility** | Infinite | Zero | Optimal balance |
+
+---
+
+## Design Principles
+
+### 1. Finite but Extensible
+
+```typescript
+// Core types are finite
+const coreNounTypes = [
+  'person', 'place', 'organization', 'thing', ...
+]
+
+// But easily extended
+brain.registerNounType('chemical_compound', {
+  keywords: ['molecule', 'compound', 'element'],
+  synonyms: ['substance', 'material'],
+  parentType: 'thing'
+})
+```
+
+### 1a. Subtypes — sub-classification without hierarchy
+
+The 42-type taxonomy is intentionally coarse. Per-product vocabulary fits on the **`subtype`** axis — a top-level standard string field on every entity. Flat by design — no hierarchy, no parent chain, no recursive resolution. That preserves the Uint32Array-backed O(1) type stats while giving consumers a place to put `'employee'` / `'customer'` / `'invoice'` / `'milestone'` without burning a slot in the global enum.
+
+```typescript
+// Same NounType, different subtypes:
+await brain.add({ type: NounType.Person,   subtype: 'employee' })
+await brain.add({ type: NounType.Person,   subtype: 'customer' })
+await brain.add({ type: NounType.Document, subtype: 'invoice'  })
+
+// Fast path — column-store hit, not metadata fallback:
+await brain.find({ type: NounType.Person, subtype: 'employee' })
+
+// Per-NounType-per-subtype counts maintained incrementally:
+brain.counts.bySubtype(NounType.Person)
+// → { employee: 12, customer: 847 }
+```
+
+Subtype has its own statistics rollup (`_system/subtype-statistics.json`) maintained alongside `nounCountsByType`, so per-subtype counts stay O(1) at billion scale.
+
+The same principle applies to **VerbTypes** (7.30+): the 127-verb taxonomy is intentionally coarse, and `subtype` is the per-product axis for relationships too. A `ReportsTo` relationship might carry `subtype: 'direct'` vs `'dotted-line'`; a `RelatedTo` edge might carry `'spouse'` / `'colleague'`. Verb-side rollup lives at `_system/verb-subtype-statistics.json` with identical shape to the noun-side rollup. Per-VerbType-per-subtype counts are O(1) via `brain.counts.byRelationshipSubtype()`. Brainy's design is fully symmetric — nouns and verbs are first-class peers with identical capability surfaces.
+
+Full guide: **[Subtypes & Facets](../guides/subtypes-and-facets.md)**.
+
+### 2. Semantic not Structural
+
+```typescript
+// NOT structural types
+type Person = {
+  name: string
+  age: number
+  // Fixed structure
+}
+
+// Semantic types
+type Noun = {
+  nounType: 'person',  // Semantic meaning!
+  metadata: {
+    noun: 'person',    // Required type
+    // Any custom fields!
+  }
+}
+```
+
+### 3. Optimizable yet Flexible
+
+```typescript
+// Optimized type tracking
+const typeIndex = new RoaringBitmap32()  // 99.76% smaller!
+
+// Flexible metadata
+const metadata = {
+  noun: 'person',          // Required type
+  customField1: 'value',   // Your fields
+  customField2: 123,       // Any structure
+  nested: { ... }          // Full flexibility
+}
+```
+
+---
+
+## Conclusion
+
+Brainy's **Finite Noun/Verb Type System** is revolutionary because it achieves the impossible:
+
+1. ✅ **Billion-scale performance** (99.76% memory reduction)
+2. ✅ **Semantic understanding** (NLP integration)
+3. ✅ **Tool compatibility** (ecosystem interoperability)
+4. ✅ **Query optimization** (type-aware planning)
+5. ✅ **Concept extraction** (via SmartExtractor for imports)
+6. ✅ **Developer experience** (clean architecture)
+7. ✅ **Flexibility** (metadata freedom within types)
+
+It's not schemaless chaos. It's not rigid relational constraints. It's **semantic structure** - the perfect balance for knowledge graphs at scale.
+
+---
+
+## Further Reading
+
+- [Storage Architecture](./storage-architecture.md) - How types enable billion-scale storage
+- [Augmentation System](./augmentations.md) - Building type-aware augmentations
+- [Query Optimization](../api/query-optimization.md) - Type-aware query planning
+- [Import Flow](../guides/import-flow.md) - How types work in the import pipeline
+
+---
+
+*Brainy's finite type system: The foundation of billion-scale, semantically-aware knowledge graphs.*

docs/architecture/index-architecture.md

@@ -0,0 +1,941 @@
+# Index Architecture
+
+Brainy uses a sophisticated **3-tier index architecture** that enables "Triple Intelligence" - the unified combination of vector similarity, graph relationships, and metadata filtering. This document provides a comprehensive architectural overview of how these indexes work internally and coordinate with each other.
+
+## Overview: The Three Main Indexes + Sub-Indexes
+
+Brainy has **3 main indexes** at the top level, each with multiple sub-indexes managed automatically:
+
+### Main Indexes (Level 1)
+
+| Index | Purpose | Data Structure | Complexity | File Location | rebuild() Method |
+|-------|---------|----------------|------------|---------------|------------------|
+| **TypeAwareVectorIndex** | Type-aware vector similarity search | 42 type-specific hierarchical graphs | O(log n) search | `src/hnsw/typeAwareHNSWIndex.ts` | ✅ Line 403 |
+| **MetadataIndexManager** | Fast metadata filtering | Chunked sparse indices with bloom filters + zone maps + roaring bitmaps | O(1) exact, O(log n) ranges | `src/utils/metadataIndex.ts` | ✅ Line 2318 |
+| **GraphAdjacencyIndex** | Relationship traversal | 2 verb-id LSM-trees + tombstone-filtered adjacency derivation | O(degree) per hop | `src/graph/graphAdjacencyIndex.ts` | ✅ Line 389 |
+
+### Sub-Indexes (Level 2)
+
+**TypeAwareVectorIndex contains:**
+- **42 type-specific vector indexes** - One per NounType (automatically rebuilt via parent)
+
+**MetadataIndexManager contains:**
+- **ChunkManager** - Adaptive chunked sparse indexing
+- **EntityIdMapper** - UUID ↔ integer mapping for roaring bitmaps
+- **FieldTypeInference** - DuckDB-inspired value-based field type detection
+- **Field Sparse Indexes** - Per-field sparse indexes with roaring bitmaps (dynamic count)
+- **Sorted Indexes** - Support orderBy queries (automatically maintained)
+- **Word Index (`__words__`)** - Text search via FNV-1a word hashes
+
+**GraphAdjacencyIndex contains:**
+- **lsmTreeSource** - Source → Targets (outgoing edges)
+- **lsmTreeTarget** - Target → Sources (incoming edges)
+- **lsmTreeVerbsBySource** - Source → Verb IDs
+- **lsmTreeVerbsByTarget** - Target → Verb IDs
+
+All indexes share a **UnifiedCache** for coordinated memory management, ensuring fair resource allocation and preventing any single index from monopolizing memory.
+
+## 1. MetadataIndex - Fast Field Filtering
+
+**Purpose**: Enable O(1) field-value lookups and O(log n) range queries on metadata fields using adaptive chunked sparse indexing.
+
+### Internal Architecture
+
+```typescript
+class MetadataIndexManager {
+  // Chunked sparse indices: field → SparseIndex (replaces flat files)
+  private sparseIndices = new Map<string, SparseIndex>()
+
+  // Chunk management
+  private chunkManager: ChunkManager
+  private chunkingStrategy: AdaptiveChunkingStrategy
+
+  // Lightweight field statistics
+  private fieldIndexes = new Map<string, FieldIndexData>()  // value → count
+  private fieldStats = new Map<string, FieldStats>()        // cardinality tracking
+
+  // Type-field affinity for NLP understanding
+  private typeFieldAffinity = new Map<string, Map<string, number>>()
+
+  // Shared memory management
+  private unifiedCache: UnifiedCache
+}
+```
+
+### Key Data Structures
+
+#### Chunked Sparse Index
+```typescript
+// SparseIndex: Directory of chunks for a field
+// Example: field="status"
+class SparseIndex {
+  field: string
+  chunks: ChunkDescriptor[]  // Metadata about each chunk
+  bloomFilters: BloomFilter[] // Fast membership testing
+}
+
+// ChunkDescriptor: Metadata about a chunk
+interface ChunkDescriptor {
+  chunkId: number
+  valueCount: number         // How many unique values in this chunk
+  idCount: number            // Total entity IDs
+  zoneMap: ZoneMap          // Min/max for range queries
+  lastUpdated: number
+}
+
+// Actual chunk data stored separately
+class ChunkData {
+  chunkId: number
+  field: string
+  entries: Map<value, RoaringBitmap32>  // ~50 values per chunk (roaring bitmaps!)
+}
+```
+
+**Performance**:
+- O(1) exact lookup with bloom filters (1% false positive rate)
+- O(log n) range queries with zone maps
+- 630x file reduction (560k flat files → 89 chunk files)
+
+#### Roaring Bitmap Optimization
+
+**Problem Solved**: JavaScript `Set<string>` for storing entity IDs was inefficient:
+- Memory overhead: ~40 bytes per UUID string (36 chars + overhead)
+- Slow intersection: JavaScript array filtering for multi-field queries
+- No hardware acceleration
+
+**Solution**: Replace `Set<string>` with `RoaringBitmap32` (WebAssembly implementation) for 90% memory savings and hardware-accelerated operations. Uses `roaring-wasm` package for universal compatibility (Node.js, browsers, serverless) without requiring native compilation.
+
+```typescript
+// EntityIdMapper: UUID ↔ Integer mapping
+class EntityIdMapper {
+  private uuidToInt = new Map<string, number>()
+  private intToUuid = new Map<number, string>()
+  private nextId = 1
+
+  getOrAssign(uuid: string): number {
+    // O(1) mapping: UUIDs → integers for bitmap storage
+    let intId = this.uuidToInt.get(uuid)
+    if (!intId) {
+      intId = this.nextId++
+      this.uuidToInt.set(uuid, intId)
+      this.intToUuid.set(intId, uuid)
+    }
+    return intId
+  }
+
+  intsIterableToUuids(ints: Iterable<number>): string[] {
+    // Convert bitmap results back to UUIDs
+    const result: string[] = []
+    for (const intId of ints) {
+      const uuid = this.intToUuid.get(intId)
+      if (uuid) result.push(uuid)
+    }
+    return result
+  }
+}
+
+// ChunkData now uses RoaringBitmap32 instead of Set<string>
+class ChunkData {
+  chunkId: number
+  field: string
+  entries: Map<string, RoaringBitmap32>  // value → bitmap of integer IDs
+}
+```
+
+**Key Benefits**:
+- **90% memory savings**: Roaring bitmaps compress much better than UUID strings
+- **Hardware-accelerated operations**: SIMD instructions (AVX2/SSE4.2) for ultra-fast bitmap AND/OR
+- **Portable serialization**: Cross-platform compatible format (Java/Go/Node.js)
+- **Lazy conversion**: UUIDs converted to integers only once, not per query
+
+**Multi-Field Intersection (THE BIG WIN!)**:
+```typescript
+// Before: JavaScript array filtering
+async getIdsForFilter(filter: {status: 'active', role: 'admin'}): Promise<string[]> {
+  // 1. Fetch UUID arrays for each field
+  const statusIds = await this.getIds('status', 'active')  // ["uuid1", "uuid2", ...]
+  const roleIds = await this.getIds('role', 'admin')       // ["uuid2", "uuid3", ...]
+
+  // 2. JavaScript intersection (SLOW!)
+  return statusIds.filter(id => roleIds.includes(id))      // O(n*m) array filtering
+}
+
+// After: Roaring bitmap intersection
+async getIdsForMultipleFields(pairs: [{field, value}, ...]): Promise<string[]> {
+  // 1. Fetch roaring bitmaps (integers, not UUIDs)
+  const bitmaps: RoaringBitmap32[] = []
+  for (const {field, value} of pairs) {
+    const bitmap = await this.getBitmapFromChunks(field, value)
+    if (!bitmap) return []  // Short-circuit if any field has no matches
+    bitmaps.push(bitmap)
+  }
+
+  // 2. Hardware-accelerated intersection (FAST! AVX2/SSE4.2 SIMD)
+  const result = RoaringBitmap32.and(...bitmaps)           // O(1) hardware operation!
+
+  // 3. Convert final bitmap to UUIDs (once, not per-field)
+  return this.idMapper.intsIterableToUuids(result)
+}
+```
+
+**Performance Impact**:
+- Multi-field intersection: **1.4x average speedup**, up to 3.3x on 10K entities
+- Memory usage: **90% reduction** (17.17 MB → 2.01 MB for 100K entities)
+- Hardware acceleration: SIMD instructions make bitmap operations nearly free
+
+**Benchmark Results** — example output from a single run of `tests/performance/roaring-bitmap-benchmark.ts` (1,000 queries per size, one machine; absolute times vary by hardware, the relative speedup and memory savings are the durable signal):
+| Dataset Size | Operation | Set Time | Roaring Time | Speedup | Memory Savings |
+|--------------|-----------|----------|--------------|---------|----------------|
+| 10,000 entities | 3-field intersection | 3.74ms | 1.14ms | **3.3x faster** | 90% |
+| 100,000 entities | 3-field intersection | 2.60ms | 1.78ms | **1.5x faster** | 88% |
+
+**Implementation**: See `src/utils/entityIdMapper.ts` and benchmark at `tests/performance/roaring-bitmap-benchmark.ts`
+
+#### Bloom Filter (Probabilistic Membership Testing)
+```typescript
+class BloomFilter {
+  bits: Uint8Array        // Bit array
+  size: number           // Total bits
+  hashCount: number      // Number of hash functions (FNV-1a, DJB2)
+
+  mightContain(value): boolean  // ~1% false positive, 0% false negative
+}
+```
+
+**Use case**: Quickly skip chunks that definitely don't contain a value
+
+#### Zone Map (Range Query Optimization)
+```typescript
+interface ZoneMap {
+  min: any | null       // Minimum value in chunk
+  max: any | null       // Maximum value in chunk
+  count: number         // Number of entries
+  hasNulls: boolean     // Whether chunk contains null values
+}
+```
+
+**Use case**: Skip entire chunks during range queries (ClickHouse-inspired)
+
+#### Type-Field Affinity
+```typescript
+// Tracks which fields are commonly used with which types
+// Example:
+// typeFieldAffinity.get('character') → {
+//   'name': 127,      // 127 characters have a 'name' field
+//   'age': 89,        // 89 characters have an 'age' field
+//   'alignment': 45   // 45 characters have an 'alignment' field
+// }
+```
+
+**Use case**: Enables NLP to understand "find characters named John" → knows 'name' is a character field
+
+#### Word Index (`__words__`) -
+```typescript
+// Special field for text/keyword search
+// Entity text content is tokenized and indexed as word hashes
+
+// Tokenization:
+// "David Smith is a software engineer" → ["david", "smith", "is", "software", "engineer"]
+
+// Word Hashing (FNV-1a):
+// "david" → hashWord("david") → 1234567  (int32)
+// "smith" → hashWord("smith") → 9876543  (int32)
+
+// Index structure (same as other fields):
+// __words__ → 1234567 → RoaringBitmap{entity1, entity5, ...}
+// __words__ → 9876543 → RoaringBitmap{entity1, entity3, ...}
+```
+
+**Design Decisions**:
+- **Max 50 words per entity**: Prevents index bloat for large documents
+- **FNV-1a hashing**: Fast, low collision rate, int32 output
+- **Min word length 2 chars**: Filters out noise words
+- **Lowercase normalization**: Case-insensitive matching
+- **Automatic integration**: Words extracted via `extractIndexableFields()`
+
+**Hybrid Search**: Text results combined with vector results using Reciprocal Rank Fusion (RRF):
+```typescript
+// RRF formula: score(d) = sum(1 / (k + rank(d)))
+// where k = 60 (standard constant)
+// alpha = weight for semantic (0 = text only, 1 = semantic only)
+```
+
+### Query Algorithm
+
+**Exact Match Query**:
+```typescript
+async getIds(field: string, value: any): Promise<string[]> {
+  // 1. Load sparse index for field
+  const sparseIndex = await this.loadSparseIndex(field)
+
+  // 2. Find candidate chunks using bloom filters
+  const candidateChunks = sparseIndex.findChunksForValue(value)
+  //    → Bloom filter checks all chunks (~1ms)
+  //    → Returns only chunks that *might* contain value
+
+  // 3. Load candidate chunks and collect IDs
+  const results = []
+  for (const chunkId of candidateChunks) {
+    const chunk = await this.chunkManager.loadChunk(field, chunkId)
+    const ids = chunk.entries.get(value)
+    if (ids) results.push(...ids)
+  }
+
+  return results
+}
+```
+
+**Range Query**:
+```typescript
+async getIdsForRange(field: string, min: any, max: any): Promise<string[]> {
+  // 1. Load sparse index for field
+  const sparseIndex = await this.loadSparseIndex(field)
+
+  // 2. Find candidate chunks using zone maps
+  const candidateChunks = sparseIndex.findChunksForRange(min, max)
+  //    → Check zoneMap.min and zoneMap.max for each chunk
+  //    → Skip chunks where max < min or min > max
+
+  // 3. Load chunks and filter values
+  const results = []
+  for (const chunkId of candidateChunks) {
+    const chunk = await this.chunkManager.loadChunk(field, chunkId)
+    for (const [value, ids] of chunk.entries) {
+      if (value >= min && value <= max) {
+        results.push(...ids)
+      }
+    }
+  }
+
+  return results
+}
+```
+
+**Benefits**:
+- Bloom filters: Skip 99% of irrelevant chunks (exact match)
+- Zone maps: Skip entire chunks that fall outside range
+- Adaptive chunking: ~50 values per chunk optimizes I/O
+- Immediate flushing: No need for dirty tracking or batch writes
+
+### Temporal Bucketing
+
+**Problem Solved**: High-cardinality timestamp fields created massive file pollution.
+- Example: 575 entities with unique timestamps → 358,407 index files (98.7% pollution!)
+
+**Solution**: Automatic bucketing of temporal fields to 1-minute intervals.
+
+```typescript
+// In normalizeValue(value, field):
+if (field && typeof value === 'number') {
+  const fieldLower = field.toLowerCase()
+  const isTemporal = fieldLower.includes('time') ||
+                     fieldLower.includes('date') ||
+                     fieldLower.includes('accessed') ||
+                     fieldLower.includes('modified') ||
+                     fieldLower.includes('created') ||
+                     fieldLower.includes('updated')
+
+  if (isTemporal) {
+    // Bucket to 1-minute intervals
+    const bucketSize = 60000 // milliseconds
+    const bucketed = Math.floor(value / bucketSize) * bucketSize
+    return bucketed.toString()
+  }
+}
+```
+
+**Benefits**:
+- ✅ Reduces 575 unique timestamps → ~10 buckets
+- ✅ File count: 358,407 → ~4,600 (98.7% reduction)
+- ✅ Zero configuration - automatic field name detection
+- ✅ Still enables range queries (not excluded like before)
+- ✅ 1-minute precision sufficient for most use cases
+
+**Field Name Detection**: Automatically buckets fields with these keywords:
+- `time`, `date`, `accessed`, `modified`, `created`, `updated`
+- Examples: `timestamp`, `createdAt`, `lastModified`, `birthdate`, `eventTime`
+
+### Operations
+
+```typescript
+// Add to index (src/brainy.ts:387)
+await this.metadataIndex.addToIndex(id, metadata)
+
+// Query exact match
+const ids = await this.metadataIndex.getIds('status', 'active')
+
+// Query range
+const ids = await this.metadataIndex.getIdsForFilter({
+  publishDate: { greaterThan: 1640995200000 }
+})
+
+// Filter discovery (what values exist for a field)
+const values = await this.metadataIndex.getFilterValues('status')
+// → ['active', 'archived', 'draft']
+
+// Statistics (O(1))
+const totalEntities = this.metadataIndex.getTotalEntityCount()
+const typeBreakdown = this.metadataIndex.getAllEntityCounts()
+// → Map { 'character': 127, 'item': 89, 'location': 45 }
+```
+
+### Excluded Fields
+
+Some fields are excluded from indexing to prevent pollution:
+
+```typescript
+const DEFAULT_EXCLUDE_FIELDS = [
+  'id',               // Primary key (redundant to index)
+  'uuid',             // Alternative primary key
+  'vector',           // High-dimensional data
+  'embedding',        // Same as vector
+  'content',          // Large text content
+  'description',      // Large text content
+  'metadata',         // Nested object (too large)
+  'data'              // Generic nested object
+]
+```
+
+**Note**: Timestamp fields like `modified`, `accessed`, `created` are NO LONGER excluded as of they are indexed with automatic bucketing.
+
+## 2. Vector Index - Vector Similarity Search
+
+**Purpose**: O(log n) semantic similarity search using vector embeddings.
+
+The default JS implementation is `JsHnswVectorIndex`; an optional native acceleration package (`@soulcraft/cor`) can register a higher-performing `VectorIndexProvider` through the plugin system. The public API stays the same either way.
+
+### Internal Architecture
+
+```typescript
+class JsHnswVectorIndex {
+  // Per-noun indexes for efficiency
+  private nouns: Map<string, HNSWNoun> = new Map()
+
+  // Global entry point for search
+  private entryPointId: string | null = null
+  private maxLevel = 0
+
+  // Shared memory management
+  private unifiedCache: UnifiedCache
+  private storage: BaseStorage | null = null
+}
+
+// Each noun has its own HNSW graph
+class HNSWNoun {
+  noun: string
+  nodes: Map<string, HNSWNode>
+  entryPointId: string | null
+  maxLevel: number
+}
+
+// Each node in the graph
+class HNSWNode {
+  id: string
+  vector: Vector | null  // Lazy-loaded from storage
+  level: number
+  connections: Map<number, string[]>  // level → neighbor IDs
+}
+```
+
+### Hierarchical Graph Structure
+
+The default vector index builds a multi-layered graph:
+
+```
+Layer 2: [entry] ←→ [node1]                    (sparse, long-range connections)
+           ↓         ↓
+Layer 1: [entry] ←→ [node1] ←→ [node2] ←→ [node3]  (medium density)
+           ↓         ↓         ↓         ↓
+Layer 0: [entry] ←→ [node1] ←→ [node2] ←→ [node3] ←→ [node4] ←→ [node5]  (dense, all nodes)
+```
+
+**Search Algorithm**:
+1. Start at entry point in top layer
+2. Greedy search for nearest neighbor in current layer
+3. Move down to next layer with found neighbor
+4. Repeat until reaching layer 0
+5. Return k nearest neighbors
+
+**Complexity**: O(log n) due to hierarchical structure
+
+### Adaptive Vector Loading
+
+Vectors are lazy-loaded on demand based on memory availability:
+
+```typescript
+private async getVectorSafe(noun: HNSWNoun): Promise<Vector> {
+  // Check UnifiedCache first
+  const cached = this.unifiedCache.get(noun.id)
+  if (cached) return cached
+
+  // Load from storage if memory available
+  if (this.unifiedCache.canCache()) {
+    const vector = await this.storage.loadVector(noun.id)
+    this.unifiedCache.set(noun.id, vector)
+    return vector
+  }
+
+  // Load transiently if memory pressure
+  return await this.storage.loadVector(noun.id)
+}
+```
+
+### Operations
+
+```typescript
+// Add entity (src/brainy.ts:add)
+await this.index.addEntity(id, vector, noun)
+
+// Search for similar vectors
+const results = await this.index.search(queryVector, k, threshold)
+// Returns: Array<{id: string, similarity: number}>
+
+// Rebuild from storage
+await this.index.rebuild()
+```
+
+## 3. GraphAdjacencyIndex - O(1) Relationship Traversal
+
+**Purpose**: Constant-time neighbor lookups regardless of graph size.
+
+### Internal Architecture
+
+```typescript
+class GraphAdjacencyIndex {
+  // O(1) bidirectional lookups
+  private sourceIndex = new Map<string, Set<string>>()  // sourceId → targetIds
+  private targetIndex = new Map<string, Set<string>>()  // targetId → sourceIds
+
+  // Full relationship data
+  private verbIndex = new Map<string, GraphVerb>()      // verbId → metadata
+
+  // Statistics
+  private relationshipCountsByType = new Map<string, number>()
+
+  // Shared memory
+  private unifiedCache: UnifiedCache
+  private storage: BaseStorage
+}
+```
+
+### Key Innovation: Bidirectional Adjacency
+
+**Core Insight**: Store BOTH directions of each relationship for O(1) lookups.
+
+```typescript
+// Example: Alice KNOWS Bob
+// verbId = "verb-123"
+
+// Source index: Alice → Bob
+sourceIndex.set('alice', Set(['bob']))
+
+// Target index: Bob ← Alice
+targetIndex.set('bob', Set(['alice']))
+
+// Full metadata
+verbIndex.set('verb-123', {
+  id: 'verb-123',
+  verb: 'knows',
+  source: 'alice',
+  target: 'bob',
+  metadata: { since: 2020 }
+})
+```
+
+**Result**: Finding Alice's friends OR Bob's friends is O(1) - just one Map lookup!
+
+### Operations
+
+```typescript
+// Add relationship (src/brainy.ts:relate)
+await this.graphIndex.addRelationship(verbId, sourceId, targetId, verb)
+
+// Get neighbors (O(1) per hop)
+const outgoing = await this.graphIndex.getNeighbors(id, 'out')  // Who does id point to?
+const incoming = await this.graphIndex.getNeighbors(id, 'in')   // Who points to id?
+const both = await this.graphIndex.getNeighbors(id, 'both')     // All neighbors
+
+// Get relationships
+const verbs = await this.graphIndex.getRelationships(sourceId, targetId)
+
+// Statistics (O(1))
+const totalRelationships = this.graphIndex.getTotalRelationshipCount()
+const byType = this.graphIndex.getRelationshipCountsByType()
+// → Map { 'knows': 45, 'created': 23, 'located_at': 12 }
+```
+
+### Graph Traversal
+
+The index supports multi-hop traversal:
+
+```typescript
+// Find all entities within 2 hops
+const reachable = await this.graphIndex.traverse({
+  startId: 'alice',
+  depth: 2,
+  direction: 'out'
+})
+// Complexity: O(V + E) breadth-first search, but each neighbor lookup is O(1)
+```
+
+## Shared Memory Management: UnifiedCache
+
+All three main indexes share a single **UnifiedCache** instance for coordinated memory management.
+
+### Architecture
+
+```typescript
+class UnifiedCache {
+  private cache: Map<string, CachedItem> = new Map()
+  private maxSize: number
+  private currentSize: number = 0
+  private evictionPolicy: 'LRU' | 'LFU' = 'LRU'
+}
+
+// Each index gets the same cache instance
+const unifiedCache = new UnifiedCache({ maxSize: 1000 })
+this.metadataIndex = new MetadataIndexManager(storage, { unifiedCache })
+this.vectorIndex = new JsHnswVectorIndex(storage, { unifiedCache })
+this.graphIndex = new GraphAdjacencyIndex(storage, { unifiedCache })
+```
+
+### Benefits
+
+1. **Fair Resource Allocation**: All indexes compete for the same memory pool
+2. **Prevents Monopolization**: No single index can starve others of memory
+3. **Coordinated Eviction**: LRU eviction across all cached items system-wide
+4. **Memory Pressure Handling**: Automatic cache shrinking when memory is tight
+5. **Adaptive Loading**: Indexes load data transiently under memory pressure
+
+### Cache Key Patterns
+
+Each index uses different key prefixes:
+
+```typescript
+// Metadata index
+cache.set(`meta:${field}:${value}`, indexEntry)
+
+// Vector index
+cache.set(`vector:${id}`, vectorData)
+
+// Graph index
+cache.set(`graph:${sourceId}`, neighbors)
+
+// Deleted items (no caching needed - uses Set)
+```
+
+## How Indexes Work Together
+
+### 1. Entity Creation (`brainy.add()`)
+
+```typescript
+// src/brainy.ts:add()
+async add(params: AddParams): Promise<string> {
+  const id = generateId()
+  const vector = await this.embedder(params.content)
+
+  // Add to metadata index (field filtering)
+  await this.metadataIndex.addToIndex(id, params.metadata)
+
+  // Add to vector index (vector search)
+  await this.index.addEntity(id, vector, params.noun)
+
+  // Relationships added via separate relate() calls
+
+  return id
+}
+```
+
+### 2. Entity Search (`brainy.find()`)
+
+```typescript
+// src/brainy.ts:find()
+async find(query: FindQuery): Promise<Result[]> {
+  let results: Result[] = []
+
+  // Step 1: Metadata filtering (fast pre-filter)
+  if (query.where) {
+    const filteredIds = await this.metadataIndex.getIdsForFilter(query.where)
+    results = await this.getEntitiesByIds(filteredIds)
+  }
+
+  // Step 2: Vector similarity search (semantic ranking)
+  if (query.like) {
+    const queryVector = await this.embedder(query.like)
+    const vectorResults = await this.index.search(queryVector, query.limit)
+
+    // Intersect or union with metadata results
+    results = this.combineResults(results, vectorResults)
+  }
+
+  // Step 3: Graph traversal (relationship filtering)
+  if (query.connected) {
+    const connectedIds = await this.graphIndex.traverse(query.connected)
+    results = results.filter(r => connectedIds.includes(r.id))
+  }
+
+  return results
+}
+```
+
+### 3. Entity Update (`brainy.update()`)
+
+```typescript
+// src/brainy.ts:update()
+async update(params: UpdateParams): Promise<void> {
+  const existing = await this.get(params.id)
+
+  // Update metadata index (remove old, add new)
+  await this.metadataIndex.removeFromIndex(params.id, existing.metadata)
+  await this.metadataIndex.addToIndex(params.id, params.metadata)
+
+  // Update vector index (re-embed if content changed)
+  if (params.content) {
+    const newVector = await this.embedder(params.content)
+    await this.index.updateEntity(params.id, newVector)
+  }
+
+  // Graph relationships unchanged (managed separately)
+}
+```
+
+### 4. Statistics (`brainy.stats()`)
+
+All indexes provide O(1) statistics:
+
+```typescript
+// src/brainy.ts:stats()
+async stats(): Promise<Statistics> {
+  return {
+    // From metadata index
+    entities: this.metadataIndex.getTotalEntityCount(),
+    entityTypes: this.metadataIndex.getAllEntityCounts(),
+
+    // From graph index
+    relationships: this.graphIndex.getTotalRelationshipCount(),
+    relationshipTypes: this.graphIndex.getRelationshipCountsByType(),
+
+    // From vector index
+    vectorIndexSize: this.index.getSize()
+  }
+}
+```
+
+### 5. Index Rebuilding (Lazy Loading Support)
+
+**Two modes of index loading:**
+
+#### Mode 1: Auto-Rebuild on init() (default)
+
+```typescript
+// src/brainy.ts:init()
+async init(): Promise<void> {
+  // When disableAutoRebuild: false (default)
+  const metadataStats = await this.metadataIndex.getStats()
+  const vectorIndexSize = this.index.size()
+  const graphIndexSize = await this.graphIndex.size()
+
+  if (metadataStats.totalEntries === 0 ||
+      vectorIndexSize === 0 ||
+      graphIndexSize === 0) {
+    // Rebuild all indexes in parallel
+    await Promise.all([
+      metadataStats.totalEntries === 0 ? this.metadataIndex.rebuild() : Promise.resolve(),
+      vectorIndexSize === 0 ? this.index.rebuild() : Promise.resolve(),
+      graphIndexSize === 0 ? this.graphIndex.rebuild() : Promise.resolve()
+    ])
+  }
+}
+```
+
+#### Mode 2: Lazy Loading on First Query
+
+```typescript
+// When disableAutoRebuild: true
+const brain = new Brainy({
+  storage: { type: 'filesystem' },
+  disableAutoRebuild: true  // Enable lazy loading
+})
+
+await brain.init()  // Returns instantly, indexes empty
+
+// First query triggers lazy rebuild
+const results = await brain.find({ limit: 10 })
+// → Calls ensureIndexesLoaded() (line 4617)
+// → Rebuilds all 3 main indexes with concurrency control
+// → Subsequent queries are instant (0ms check)
+```
+
+**Performance:**
+- First query with lazy loading: ~50-200ms rebuild (1K-10K entities)
+- Concurrent queries: Wait for same rebuild (mutex prevents duplicates)
+- Subsequent queries: 0ms check (instant)
+
+See [initialization-and-rebuild.md](./initialization-and-rebuild.md) for detailed lazy loading implementation.
+
+## Triple Intelligence Integration
+
+The **TripleIntelligenceSystem** (`src/triple/TripleIntelligenceSystem.ts`) combines all three core indexes:
+
+```typescript
+class TripleIntelligenceSystem {
+  constructor(
+    private metadataIndex: MetadataIndexManager,
+    private vectorIndex: VectorIndexProvider,
+    private graphIndex: GraphAdjacencyIndex,
+    private embedder: EmbedderFunction,
+    private storage: BaseStorage
+  ) {}
+
+  async query(nlpQuery: string): Promise<Result[]> {
+    // Parse natural language
+    const parsed = await this.parseQuery(nlpQuery)
+
+    // Execute across all three indexes
+    const [metadataResults, vectorResults, graphResults] = await Promise.all([
+      this.metadataIndex.getIdsForFilter(parsed.filters),
+      this.vectorIndex.search(parsed.vector, parsed.limit),
+      this.graphIndex.traverse(parsed.graphConstraints)
+    ])
+
+    // Fuse results with weighted scoring
+    return this.fuseResults(metadataResults, vectorResults, graphResults)
+  }
+}
+```
+
+## Performance Characteristics
+
+### Operation Complexity by Index
+
+| Operation | MetadataIndexManager | TypeAwareVectorIndex | GraphAdjacencyIndex |
+|-----------|---------------------|-------------------|---------------------|
+| **Add** | O(1) per field | O(log n) | O(1) |
+| **Remove** | O(1) per field | O(log n) | O(1) |
+| **Exact lookup** | O(1) | N/A | O(1) |
+| **Range query** | O(log n) + O(k) | N/A | N/A |
+| **Similarity search** | N/A | O(log n) | N/A |
+| **Neighbor lookup** | N/A | N/A | O(1) |
+| **Statistics** | O(1) | O(1) | O(1) |
+| **Rebuild** | O(n) | O(n) | O(n) |
+
+Where:
+- n = total number of entities
+- k = number of matching results
+
+**Note**: All 3 main indexes have rebuild() methods that load persisted data (O(n)) rather than recomputing (which would be O(n log n) for the vector index).
+
+### Memory Footprint
+
+| Index | Per-Entity Memory | Notes |
+|-------|-------------------|-------|
+| **MetadataIndexManager** | ~100 bytes | Depends on field count and cardinality (RoaringBitmap32 compression) |
+| **TypeAwareVectorIndex** | ~1.5 KB | Vector (384 dims × 4 bytes) + graph connections across 42 type-specific indexes |
+| **GraphAdjacencyIndex** | ~50 bytes per relationship | Bidirectional verb-id references in 2 LSM-trees |
+
+**Total overhead**: ~1.6 KB per entity + ~50 bytes per relationship
+
+**Sub-index memory:**
+- ChunkManager: ~20 bytes per chunk descriptor
+- EntityIdMapper: ~32 bytes per UUID mapping (50-90% savings vs Set\<string\>)
+- LSM-trees: ~200 bytes per relationship (SSTable storage)
+
+### Scalability
+
+All indexes scale gracefully. The cost of each stage is governed by its algorithmic complexity, not a fixed millisecond figure — absolute latency depends on hardware, embedding model, and storage backend. Only the graph adjacency index carries a committed scale assertion:
+
+| Query stage | Complexity | Scaling behavior |
+|-------------|------------|------------------|
+| Metadata filter (exact) | O(1) | Constant — independent of dataset size |
+| Metadata filter (range) | O(log n) + O(k) | Sub-linear; k = matching results |
+| Vector search (HNSW) | O(log n) | Degrades gracefully via hierarchical layers |
+| Graph hop | O(1) | Measured <1 ms per neighbor lookup, validated up to 1M relationships (`tests/performance/graph-scale-performance.test.ts:238`) |
+| Combined query | O(log n) | Bounded by the vector stage; metadata and graph stages stay O(1)/O(log n) |
+
+**Key observations**:
+- Graph queries stay O(1) regardless of scale
+- Metadata filtering scales sub-linearly
+- Vector search degrades gracefully due to the hierarchical index
+- Combined queries remain fast even at scale
+
+## Best Practices
+
+### When to Use Each Index
+
+**MetadataIndex**:
+- Filtering by exact field values (status, type, category)
+- Range queries on numeric/temporal fields (dates, prices, counts)
+- Field discovery (what filters are available)
+- Type-based querying (find all characters, all items)
+
+**Vector Index**:
+- Semantic similarity search ("find similar documents")
+- Content-based retrieval ("find posts about AI")
+- Fuzzy matching (when exact matches aren't required)
+- Recommendation systems (find related items)
+
+**GraphAdjacencyIndex**:
+- Relationship queries ("who knows whom")
+- Path finding ("how are these entities connected")
+- Network analysis ("find communities")
+- Multi-hop traversal ("friends of friends")
+
+**Note**: Soft-delete functionality is not currently integrated. Brainy uses hard deletes via storage layer.
+
+### Query Optimization
+
+1. **Start with metadata filters** - They're fastest and most selective
+2. **Use graph constraints** - O(1) lookups significantly reduce search space
+3. **Vector search last** - Most expensive, best used on pre-filtered set
+4. **Leverage temporal bucketing** - Timestamp range queries work efficiently
+5. **Monitor statistics** - Use O(1) stats methods for cardinality estimation
+
+### Memory Management
+
+1. **Configure UnifiedCache appropriately** - Balance between speed and memory
+2. **Use lazy loading** - Vector index loads vectors on-demand
+3. **Monitor cache hit rates** - Adjust cache size if hit rate is low
+4. **Consider storage adapter** - Memory = fastest, filesystem = persistent
+
+## Related Documentation
+
+- [Find System](../FIND_SYSTEM.md) - Query-centric view of index usage
+- [Triple Intelligence](./triple-intelligence.md) - Advanced query system
+- [Storage Architecture](./storage-architecture.md) - Storage layer details
+- [Performance Guide](../PERFORMANCE.md) - Performance tuning
+- [Overview](./overview.md) - High-level architecture
+
+## Summary: Index Hierarchy
+
+### Level 1: Main Indexes (3)
+All have rebuild() methods and are covered by lazy loading:
+1. **TypeAwareVectorIndex** - `src/hnsw/typeAwareHNSWIndex.ts:403`
+2. **MetadataIndexManager** - `src/utils/metadataIndex.ts:2318`
+3. **GraphAdjacencyIndex** - `src/graph/graphAdjacencyIndex.ts:389`
+
+### Level 2: Sub-Indexes (~50+)
+Automatically managed by parent rebuild():
+- **42 type-specific vector indexes** (one per NounType)
+- **6 metadata components** (ChunkManager, EntityIdMapper, FieldTypeInference, Field Sparse Indexes, Sorted Indexes)
+- **2 LSM-trees** (lsmTreeVerbsBySource, lsmTreeVerbsByTarget — the verb set is the single adjacency source of truth; neighbor reads derive from live verbs so removals are honored)
+- **In-memory graph structures** (sourceIndex, targetIndex, verbIndex)
+
+### Lazy Loading
+- **Mode 1**: Auto-rebuild on init() (default)
+- **Mode 2**: Lazy rebuild on first query (when `disableAutoRebuild: true`)
+- **Concurrency-safe**: Mutex prevents duplicate rebuilds
+- **Performance**: First query ~50-200ms, subsequent queries instant
+
+### Total Functional Index Count
+- **3 main indexes** with independent rebuild() methods
+- **~50+ sub-components** managed automatically
+- **All covered** by rebuildIndexesIfNeeded() or built-in lazy initialization
+
+## Version History
+
+- **v5.7.7** (November 2025): Added production-scale lazy loading with concurrency control. Fixed critical bug where `disableAutoRebuild: true` left indexes empty forever. Added `ensureIndexesLoaded()` helper and `getIndexStatus()` diagnostic.
+- **v3.43.0** (October 2025): Migrated from `roaring` (native C++) to `roaring-wasm` (WebAssembly) for universal compatibility. No API changes - maintains identical RoaringBitmap32 interface. Benefits: works in all environments (Node.js, browsers, serverless) without build tools, zero compilation errors, simpler developer experience. 90% memory savings and hardware-accelerated operations unchanged.
+- **v3.42.0** (October 2025): Replaced flat file indexing with adaptive chunked sparse indexing. Bloom filters + zone maps for O(1) exact match and O(log n) range queries. 630x file reduction (560k → 89 files). Removed dual code paths.
+- **v3.41.0** (October 2025): Added automatic temporal bucketing to MetadataIndex
+- **v3.40.0** (October 2025): Enhanced batch processing for imports
+- **v3.0.0** (September 2025): Introduced 3-tier index architecture with UnifiedCache

docs/architecture/initialization-and-rebuild.md

@@ -0,0 +1,713 @@
+# Initialization and Rebuild Processes
+
+This document explains how Brainy's four indexes (MetadataIndex, vector index, GraphAdjacencyIndex, DeletedItemsIndex) initialize and rebuild from persisted storage.
+
+## Core Principle: All Indexes Are Disk-Based
+
+**KEY INSIGHT**: All indexes in Brainy are already disk-based. There is no need for snapshots or separate backup mechanisms. Initialization simply loads the right amount of data from storage into memory based on available resources.
+
+### What Gets Persisted
+
+| Index | Persisted Data | Storage Method | Since Version |
+|-------|---------------|----------------|---------------|
+| **MetadataIndex** | Field registry + chunked sparse indices with bloom filters + zone maps | `storage.saveMetadata()` | v3.42.0 (chunks), v4.2.1 (registry) |
+| **Vector Index** | Vector embeddings + graph connections | `storage.saveHNSWData()` + `storage.saveHNSWSystem()` | v3.35.0 |
+| **GraphAdjacencyIndex** | Relationships via LSM-tree SSTables | LSM-tree auto-persistence | v3.44.0 |
+| **DeletedItemsIndex** | Set of deleted IDs | `storage.saveDeletedItems()` | v3.0.0 |
+
+#### MetadataIndex Persistence Details
+
+The MetadataIndex now persists two components:
+
+1. **Field Registry** (`__metadata_field_registry__`): Directory of indexed fields for O(1) discovery
+   - Size: ~4-8KB (50-200 fields typical)
+   - Enables instant cold starts by discovering persisted indices
+   - Auto-saved during every flush operation
+
+2. **Sparse Indices** (`__sparse_index__<field>`): Per-field index directories
+   - Contains chunk metadata, zone maps, and bloom filters
+   - Lazy-loaded via UnifiedCache on first query
+
+3. **Chunks** (`__metadata_chunk__<field>_<chunkId>`): Actual inverted index data
+   - Roaring bitmaps for compressed entity ID storage
+   - Loaded on-demand based on query patterns
+
+All storage operations use the **StorageAdapter** interface, which works with FileSystem and Memory backends.
+
+## Initialization Process
+
+### 1. Lazy Initialization Pattern
+
+All indexes use lazy initialization - they don't load data until first use:
+
+```typescript
+// Example: GraphAdjacencyIndex
+class GraphAdjacencyIndex {
+  private initialized = false
+
+  private async ensureInitialized(): Promise<void> {
+    if (this.initialized) return
+
+    // Initialize LSM-trees from storage
+    await this.lsmTreeSource.init()
+    await this.lsmTreeTarget.init()
+
+    this.initialized = true
+  }
+
+  // Every public method calls ensureInitialized() first
+  async getNeighbors(id: string): Promise<string[]> {
+    await this.ensureInitialized()  // Lazy init!
+    // ... actual logic
+  }
+}
+```
+
+**Benefits**:
+- Zero-cost abstraction: No initialization overhead if index not used
+- Faster startup: Indexes initialize in parallel on first use
+- Lower memory: Only used indexes consume memory
+
+### 2. Brain Initialization Flow
+
+When you create a `Brain` instance and call `init()`, behavior depends on the `disableAutoRebuild` configuration:
+
+#### Mode 1: Auto-Rebuild on init() (Default)
+
+```typescript
+// src/brainy.ts (lines 192-237)
+async init(): Promise<void> {
+  const initStartTime = Date.now()
+
+  // STEP 1: Initialize storage and unified cache
+  await this.storage.init()
+
+  // STEP 2: Check index sizes (lazy initialization triggers here)
+  const metadataStats = await this.metadataIndex.getStats()
+  const vectorIndexSize = this.index.size()
+  const graphIndexSize = await this.graphIndex.size()
+
+  // STEP 3: Rebuild empty indexes from storage in parallel
+  if (metadataStats.totalEntries === 0 ||
+      vectorIndexSize === 0 ||
+      graphIndexSize === 0) {
+
+    const rebuildStartTime = Date.now()
+    await Promise.all([
+      metadataStats.totalEntries === 0
+        ? this.metadataIndex.rebuild()
+        : Promise.resolve(),
+      vectorIndexSize === 0
+        ? this.index.rebuild()
+        : Promise.resolve(),
+      graphIndexSize === 0
+        ? this.graphIndex.rebuild()
+        : Promise.resolve()
+    ])
+
+    const rebuildDuration = Date.now() - rebuildStartTime
+    console.log(`✅ All indexes rebuilt in ${rebuildDuration}ms`)
+  }
+
+  // STEP 4: Log statistics
+  const stats = await this.stats()
+  console.log(`📊 Brain initialized with ${stats.entities} entities`)
+}
+```
+
+**Timeline** (typical cold start with 10K entities):
+- 0-50ms: Storage adapter initialization
+- 50-100ms: Field registry loading (O(1) discovery of persisted indices)
+- 100-200ms: Index lazy initialization (LSM-tree loading)
+- 200-500ms: Cache warming (preload common fields)
+- **No rebuild needed!** Registry discovers existing indices
+- Total: ~0.5-1 second (instant cold starts)
+
+**Timeline** (cold start WITHOUT field registry - first run only):
+- 0-50ms: Storage adapter initialization
+- 50-100ms: Index lazy initialization
+- 100-2000ms: One-time rebuild to create indices
+- Total: ~1-3 seconds (one time only)
+
+#### Mode 2: Lazy Loading on First Query
+
+When `disableAutoRebuild: true`, indexes remain empty after init() and rebuild on first query:
+
+```typescript
+// User code
+const brain = new Brainy({
+  storage: { type: 'filesystem' },
+  disableAutoRebuild: true  // Enable lazy loading
+})
+
+await brain.init()  // Returns instantly (0-10ms)
+
+// First query triggers lazy rebuild
+const results = await brain.find({ limit: 10 })
+// → Calls ensureIndexesLoaded() internally (brainy.ts:4617)
+// → Rebuilds all 3 main indexes with concurrency control
+// → Returns results (~50-200ms total for 1K-10K entities)
+
+// Subsequent queries are instant
+const more = await brain.find({ limit: 100 })  // 0ms check, instant
+```
+
+**ensureIndexesLoaded() Implementation** (brainy.ts:4617-4664):
+```typescript
+private async ensureIndexesLoaded(): Promise<void> {
+  // Fast path: Already loaded
+  if (this.lazyRebuildCompleted) {
+    return  // 0ms
+  }
+
+  // Concurrency control: Wait for in-progress rebuild
+  if (this.lazyRebuildInProgress && this.lazyRebuildPromise) {
+    await this.lazyRebuildPromise  // Wait for same rebuild
+    return
+  }
+
+  // Check if storage has data
+  const entities = await this.storage.getNouns({ pagination: { limit: 1 } })
+  const hasData = (entities.totalCount && entities.totalCount > 0) || entities.items.length > 0
+
+  if (!hasData) {
+    this.lazyRebuildCompleted = true
+    return
+  }
+
+  // Start lazy rebuild with mutex
+  this.lazyRebuildInProgress = true
+  this.lazyRebuildPromise = this.rebuildIndexesIfNeeded(true)
+    .then(() => {
+      this.lazyRebuildCompleted = true
+    })
+    .finally(() => {
+      this.lazyRebuildInProgress = false
+      this.lazyRebuildPromise = null
+    })
+
+  await this.lazyRebuildPromise
+}
+```
+
+**Lazy Loading Performance:**
+- First query: ~50-200ms (1K-10K entities) - triggers rebuild
+- Concurrent queries: Wait for same rebuild (mutex prevents duplicates)
+- Subsequent queries: 0ms check (instant)
+- Zero-config: Works automatically, no code changes needed
+
+**Use Cases for Lazy Loading:**
+- **Serverless/Edge**: Minimize cold start time, indexes load on demand
+- **Development**: Faster restarts during development
+- **Large datasets**: Defer index loading until actually needed
+- **Read-heavy workloads**: Write operations don't wait for index rebuild
+
+## Rebuild Process
+
+### What "Rebuild" Actually Means
+
+**IMPORTANT**: "Rebuild" does NOT mean recomputing data. It means:
+1. **Load persisted data** from storage (vector index connections, metadata chunks, LSM-tree SSTables)
+2. **Populate in-memory structures** (Maps, Sets, graphs)
+3. **Apply adaptive caching** (preload vectors if small dataset, lazy load if large)
+
+**Complexity**: O(N) - linear scan through storage, NOT O(N log N) recomputation!
+
+### 1. Vector Index Rebuild (Correct Pattern)
+
+```typescript
+// src/hnsw/hnswIndex.ts (lines 809-947)
+public async rebuild(options: {
+  lazy?: boolean
+  batchSize?: number
+  onProgress?: (loaded: number, total: number) => void
+} = {}): Promise<void> {
+  // STEP 1: Clear in-memory structures
+  this.clear()
+
+  // STEP 2: Load system data (entry point, max level)
+  const systemData = await this.storage.getHNSWSystem()
+  this.entryPointId = systemData.entryPointId
+  this.maxLevel = systemData.maxLevel
+
+  // STEP 3: Determine preloading strategy (adaptive caching)
+  const totalNouns = await this.storage.getNounCount()
+  const vectorMemory = totalNouns * 384 * 4  // 384 dims × 4 bytes
+  const availableCache = this.unifiedCache.getRemainingCapacity()
+  const shouldPreload = vectorMemory < availableCache * 0.3
+
+  // STEP 4: Load entities with persisted vector index connections
+  let hasMore = true
+  let cursor: string | undefined = undefined
+
+  while (hasMore) {
+    const result = await this.storage.getNouns({
+      pagination: { limit: 1000, cursor }
+    })
+
+    for (const nounData of result.items) {
+      // Load vector graph data from storage (NOT recomputed!)
+      const hnswData = await this.storage.getHNSWData(nounData.id)
+
+      // Create noun with restored connections
+      const noun: HNSWNoun = {
+        id: nounData.id,
+        vector: shouldPreload ? nounData.vector : [],  // Adaptive!
+        connections: new Map(),
+        level: hnswData.level
+      }
+
+      // Restore connections from persisted data
+      for (const [levelStr, nounIds] of Object.entries(hnswData.connections)) {
+        const level = parseInt(levelStr, 10)
+        noun.connections.set(level, new Set<string>(nounIds))
+      }
+
+      // Just add to memory (no recomputation!)
+      this.nouns.set(nounData.id, noun)
+    }
+
+    hasMore = result.hasMore
+    cursor = result.nextCursor
+  }
+}
+```
+
+**Key Points**:
+- ✅ Loads vector index connections from storage via `getHNSWData()`
+- ✅ Uses adaptive caching (preload vectors if < 30% of available cache)
+- ✅ O(N) complexity - just loads existing data
+- ❌ Does NOT call `addItem()` which would recompute connections (O(N log N))
+
+### 2. TypeAwareVectorIndex Rebuild (Fixed in v3.45.0)
+
+**Critical Architectural Fix**: The type-aware vector index previously had TWO major bugs:
+
+1. **Bug #1**: Called `addItem()` during rebuild → O(N log N) recomputation instead of O(N) loading
+2. **Bug #2**: Loaded ALL nouns 31 times in parallel (once per type) → O(31*N) complexity causing timeouts
+
+Both were fixed in v3.45.0 by loading ALL nouns ONCE and routing to correct type indexes:
+
+```typescript
+// src/hnsw/typeAwareHNSWIndex.ts (lines 379-571)
+public async rebuild(options?: {
+  lazy?: boolean
+  batchSize?: number
+  onProgress?: (loaded: number, total: number) => void
+}): Promise<void> {
+  // STEP 1: Clear all type-specific indexes
+  for (const index of this.typeIndexes.values()) {
+    index.clear()
+  }
+
+  // STEP 2: Determine preloading strategy (same as vector index)
+  const totalNouns = await this.storage.getNounCount()
+  const vectorMemory = totalNouns * 384 * 4
+  const availableCache = this.unifiedCache.getRemainingCapacity()
+  const shouldPreload = vectorMemory < availableCache * 0.3
+
+  // STEP 3: Load entities grouped by type
+  for (const nounType of ALL_NOUN_TYPES) {
+    const index = this.getOrCreateIndex(nounType)
+    let hasMore = true
+    let cursor: string | undefined = undefined
+
+    while (hasMore) {
+      const result = await this.storage.getNouns({
+        type: nounType,
+        pagination: { limit: 1000, cursor }
+      })
+
+      for (const nounData of result.items) {
+        // CORRECT: Load persisted vector index data (not recomputed!)
+        const hnswData = await this.storage.getHNSWData(nounData.id)
+
+        const noun = {
+          id: nounData.id,
+          vector: shouldPreload ? nounData.vector : [],
+          connections: new Map(),
+          level: hnswData.level
+        }
+
+        // Restore connections from storage
+        for (const [levelStr, nounIds] of Object.entries(hnswData.connections)) {
+          const level = parseInt(levelStr, 10)
+          noun.connections.set(level, new Set<string>(nounIds))
+        }
+
+        // Add to in-memory index (no recomputation!)
+        index.nouns.set(nounData.id, noun)
+      }
+
+      hasMore = result.hasMore
+      cursor = result.nextCursor
+    }
+  }
+}
+```
+
+**Bug Fix**: Changed from `index.addItem()` (recomputation) to direct `nouns.set()` (restoration).
+
+**Performance Impact**: 200-600x speedup (5 minutes → 500ms for 10K entities)
+
+**Correct Pattern**:
+```typescript
+// Load ALL nouns ONCE (not 31 times!)
+while (hasMore) {
+  const result = await storage.getNounsWithPagination({ limit: 1000, cursor })
+
+  for (const noun of result.items) {
+    const type = noun.nounType || noun.metadata?.noun
+    const index = this.getIndexForType(type)
+
+    // Load persisted HNSW data
+    const hnswData = await storage.getHNSWData(noun.id)
+
+    // Restore connections (not recompute!)
+    const restoredNoun = {
+      id: noun.id,
+      vector: shouldPreload ? noun.vector : [],
+      connections: restoreConnections(hnswData),
+      level: hnswData.level
+    }
+
+    // Add to correct type index
+    index.nouns.set(noun.id, restoredNoun)
+  }
+
+  cursor = result.nextCursor
+  hasMore = result.hasMore
+}
+```
+
+**Performance Improvements**:
+- 31x speedup: Load nouns ONCE instead of 31 times (O(N) vs O(31*N))
+- 200-600x speedup: Load from storage instead of recomputing (O(N) vs O(N log N))
+- **Combined**: ~6000x speedup! (150 minutes → 1.5 seconds for 10K entities)
+
+### 3. MetadataIndex Rebuild (v4.2.1+ with Field Registry)
+
+**v4.2.1 Critical Fix**: Field registry persistence eliminates unnecessary rebuilds!
+
+```typescript
+// src/utils/metadataIndex.ts (lines 202-216)
+async init(): Promise<void> {
+  // STEP 1: Load field registry to discover persisted indices
+  // This is THE KEY FIX - O(1) discovery of existing indices
+  await this.loadFieldRegistry()
+
+  // If registry found, fieldIndexes Map is now populated
+  // getStats() will return totalEntries > 0 → skips rebuild!
+
+  // STEP 2: Initialize EntityIdMapper
+  await this.idMapper.init()
+
+  // STEP 3: Warm cache with discovered fields
+  await this.warmCache()
+}
+
+async loadFieldRegistry(): Promise<void> {
+  const registry = await this.storage.getMetadata('__metadata_field_registry__')
+
+  if (registry?.fields) {
+    // Populate fieldIndexes Map from discovered fields
+    // Sparse indices are lazy-loaded when first accessed
+    for (const field of registry.fields) {
+      this.fieldIndexes.set(field, {
+        values: {},
+        lastUpdated: registry.lastUpdated
+      })
+    }
+    // Result: getStats() now returns totalEntries > 0
+    // → Brain skips rebuild, cold start in 2-3 seconds!
+  }
+}
+```
+
+**Rebuild Only Happens If**:
+1. **First run** (no field registry exists yet)
+2. **Registry corruption** (rare)
+3. **Explicit rebuild request** (manual operation)
+
+```typescript
+// Only runs if field registry not found
+async rebuild(): Promise<void> {
+  // STEP 1: Clear in-memory structures
+  this.fieldIndexes.clear()
+
+  // STEP 2: Load all entity metadata and rebuild indices
+  // Sequential batching (25/batch) to prevent socket exhaustion
+  // After rebuild: Field registry saved during next flush()
+
+  // One-time cost: ~2-3 seconds for 1K entities
+}
+```
+
+**Performance Comparison**:
+
+| Version | Cold Start | Discovery Method | Rebuild Needed? |
+|---------|------------|------------------|-----------------|
+| v4.2.0 | 8-9 min | None (always rebuild) | Always |
+| v4.2.1 | 2-3 sec | Field registry O(1) | First run only |
+
+**Key Points**:
+- ✅ Field registry enables O(1) discovery (4-8KB file)
+- ✅ Sparse indices lazy-loaded on first query
+- ✅ Bloom filters + zone maps loaded for fast filtering
+- ✅ One-time rebuild on first run, then instant restarts forever
+- ✅ Automatic: No configuration needed
+
+### 4. GraphAdjacencyIndex Rebuild
+
+```typescript
+// src/graph/graphAdjacencyIndex.ts (lines 279-336)
+async rebuild(): Promise<void> {
+  // STEP 1: Clear in-memory caches
+  this.verbIndex.clear()
+  this.relationshipCountsByType.clear()
+
+  // STEP 2: Load all verbs from storage
+  let hasMore = true
+  let cursor: string | undefined = undefined
+
+  while (hasMore) {
+    const result = await this.storage.getVerbs({
+      pagination: { limit: 1000, cursor }
+    })
+
+    for (const verb of result.items) {
+      // Add to index (which updates LSM-trees)
+      await this.addVerb(verb)
+    }
+
+    hasMore = result.hasMore
+    cursor = result.nextCursor
+  }
+
+  // Note: LSM-trees (lsmTreeSource, lsmTreeTarget) are already
+  // initialized from persisted SSTables during ensureInitialized()
+}
+```
+
+**Key Points**:
+- ✅ LSM-tree SSTables already loaded during `init()`
+- ✅ Rebuild just repopulates verb cache
+- ✅ O(E) complexity where E = number of edges
+
+## Adaptive Memory Management
+
+### Strategy: Preload vs Lazy Load
+
+All indexes use the **UnifiedCache** to determine memory allocation:
+
+```typescript
+// Decision logic (in all indexes)
+const totalDataSize = estimateDataSize()
+const availableCache = unifiedCache.getRemainingCapacity()
+
+if (totalDataSize < availableCache * 0.3) {
+  // PRELOAD: Dataset is small relative to available memory
+  // Load everything into memory for maximum performance
+  shouldPreload = true
+} else {
+  // LAZY LOAD: Dataset is large
+  // Load on-demand with LRU eviction
+  shouldPreload = false
+}
+```
+
+**Thresholds**:
+- **< 30% of available cache**: Preload all vectors
+- **> 30% of available cache**: Lazy load on demand
+
+**Example** (default 100MB cache):
+- 10K entities × 1.5KB = 15MB → **Preload** (15MB < 30MB)
+- 100K entities × 1.5KB = 150MB → **Lazy load** (150MB > 30MB)
+
+### UnifiedCache Integration
+
+```typescript
+// All indexes share the same cache
+const unifiedCache = getGlobalCache()  // Singleton, 100MB default
+
+// MetadataIndex
+this.unifiedCache = unifiedCache
+
+// Vector index
+this.unifiedCache = unifiedCache
+
+// GraphAdjacencyIndex
+this.unifiedCache = unifiedCache
+```
+
+**Benefits**:
+- Fair resource allocation across indexes
+- Prevents any single index from monopolizing memory
+- Coordinated LRU eviction system-wide
+
+## Performance Characteristics
+
+### Rebuild Times (Typical Hardware)
+
+| Dataset Size | Metadata | Vector | Graph | Total (Parallel) |
+|--------------|----------|------|-------|------------------|
+| 1K entities | 50ms | 100ms | 30ms | **150ms** |
+| 10K entities | 200ms | 500ms | 150ms | **600ms** |
+| 100K entities | 1s | 3s | 1s | **3.5s** |
+| 1M entities | 8s | 25s | 10s | **28s** |
+
+**Note**: Parallel rebuild means total time ≈ max(individual times), not sum.
+
+### Memory Overhead
+
+| Index | In-Memory Overhead | Disk Storage |
+|-------|-------------------|--------------|
+| **MetadataIndex** | ~100 bytes/entity | ~500 bytes/entity (chunks) |
+| **Vector Index** | ~200 bytes/entity (no vectors) | ~1.5 KB/entity (vectors + connections) |
+| **GraphAdjacencyIndex** | ~128 bytes/relationship | ~200 bytes/relationship (LSM-tree) |
+| **DeletedItemsIndex** | ~40 bytes/deleted ID | ~50 bytes/deleted ID |
+
+**Total overhead** (lazy loading):
+- **In-memory**: ~300 bytes per entity + ~128 bytes per relationship
+- **On-disk**: ~2 KB per entity + ~200 bytes per relationship
+
+### O(N) vs O(N log N) Comparison
+
+**Before fix** (TypeAwareVectorIndex bug):
+```typescript
+// BAD: Recomputes vector index connections during rebuild
+for (const noun of nouns) {
+  await index.addItem(noun)  // O(log N) per item → O(N log N) total
+}
+// 10K entities: ~5 minutes
+```
+
+**After fix** (correct pattern):
+```typescript
+// GOOD: Loads connections from storage
+for (const noun of nouns) {
+  const hnswData = await storage.getHNSWData(noun.id)  // O(1) per item
+  noun.connections = restoreConnections(hnswData)      // O(1) per item
+  index.nouns.set(noun.id, noun)                       // O(1) per item
+}
+// 10K entities: ~500ms (600x faster!)
+```
+
+## Common Patterns
+
+### Cold Start (Empty Storage)
+
+```typescript
+const brain = new Brain({ storage })
+
+// First init: All indexes are empty
+await brain.init()
+// → No rebuild needed, indexes start empty
+
+// Add data
+await brain.add({ content: 'Hello', noun: 'message' })
+
+// Second init: Indexes populated
+const brain2 = new Brain({ storage })
+await brain2.init()
+// → Rebuilds all indexes from storage (~1-3s for 10K entities)
+```
+
+### Warm Start (Storage Already Populated)
+
+```typescript
+const brain = new Brain({ storage })
+
+// Init with existing data
+await brain.init()
+// → Detects non-empty storage
+// → Rebuilds indexes in parallel
+// → Uses adaptive caching (preload if small, lazy if large)
+```
+
+### Manual Rebuild
+
+```typescript
+const brain = new Brain({ storage })
+await brain.init()
+
+// Force rebuild (e.g., after data corruption)
+await brain.metadataIndex.rebuild()
+await brain.index.rebuild()
+await brain.graphIndex.rebuild()
+```
+
+## Troubleshooting
+
+### Slow Rebuild Times
+
+**Symptom**: Rebuild takes minutes instead of seconds
+
+**Diagnosis**:
+```typescript
+// Check if rebuild is recomputing instead of loading
+console.time('rebuild')
+await brain.index.rebuild()
+console.timeEnd('rebuild')
+
+// For 10K entities:
+// - Expected: 500-800ms (loading from storage)
+// - Bug: 5-10 minutes (recomputing vector index connections)
+```
+
+**Solution**: Ensure index is loading from storage, not calling `addItem()` during rebuild.
+
+### High Memory Usage
+
+**Symptom**: Memory usage exceeds expectations
+
+**Diagnosis**:
+```typescript
+// Check if vectors are being preloaded
+const stats = brain.index.getStats()
+console.log('Preloaded vectors:', stats.preloadedVectors)
+
+// Expected:
+// - Small dataset (< 30% cache): Most vectors preloaded
+// - Large dataset (> 30% cache): Few vectors preloaded
+```
+
+**Solution**: Adjust `UnifiedCache` size or force lazy loading:
+```typescript
+const brain = new Brain({
+  storage,
+  cache: { maxSize: 50 * 1024 * 1024 }  // 50MB cache
+})
+```
+
+### Missing Data After Rebuild
+
+**Symptom**: Entities disappear after restart
+
+**Diagnosis**:
+```typescript
+// Check storage persistence
+const nouns = await storage.getNouns({ pagination: { limit: 10 } })
+console.log('Nouns in storage:', nouns.items.length)
+
+// If empty: Storage not persisting
+// If populated: Rebuild not loading correctly
+```
+
+**Solution**: Verify storage adapter is configured correctly (e.g., FileSystem path exists).
+
+## Related Documentation
+
+- [Index Architecture](./index-architecture.md) - Data structures and operations
+- [Storage Architecture](./storage-architecture.md) - Storage layer details
+- [Performance Guide](../PERFORMANCE.md) - Performance tuning
+- [Scaling Guide](../SCALING.md) - Large dataset optimization
+
+## Version History
+
+- **v5.7.7** (November 2025): Added production-scale lazy loading with `ensureIndexesLoaded()` helper. Fixed critical bug where `disableAutoRebuild: true` left indexes empty forever. Added concurrency control (mutex) to prevent duplicate rebuilds from concurrent queries. Added `getIndexStatus()` diagnostic method. Zero-config operation - works automatically.
+- **v3.45.0** (October 2025): Fixed type-aware vector index `rebuild()` to load from storage instead of recomputing. Removed all snapshot code (unnecessary with correct rebuild pattern). 200-600x speedup.
+- **v3.44.0** (October 2025): GraphAdjacencyIndex migrated to LSM-tree storage for billion-scale relationships
+- **v3.42.0** (October 2025): MetadataIndex migrated to chunked sparse indexing
+- **v3.35.0** (August 2025): Vector index connections first persisted to storage
+- **v3.0.0** (September 2025): Initial 3-tier index architecture

docs/architecture/multiprocess-storage-mixin.md

@@ -0,0 +1,134 @@
+# Design note: multi-process storage mixin
+
+**Status:** Proposed (future minor)
+**Owner:** Brainy core
+**Filed:** 2026-05-15
+**Companion:** [`concepts/storage-adapters`](../concepts/storage-adapters.md)
+
+## Context
+
+Brainy 7.21 added seven storage-adapter methods to support multi-process
+safety:
+
+```
+supportsMultiProcessLocking()
+acquireWriterLock(opts)
+releaseWriterLock()
+readWriterLock()
+startFlushRequestWatcher(cb)
+stopFlushRequestWatcher()
+requestFlushOverFilesystem(timeoutMs)
+```
+
+They live on `BaseStorage` as no-op defaults and are overridden on
+`FileSystemStorage` with real implementations. Any adapter extending
+`FileSystemStorage` (e.g. Cor's `MmapFileSystemStorage`) inherits the
+real ones for free.
+
+This works correctly today. The question is whether the methods *belong*
+on `BaseStorage`.
+
+## The case for moving them out
+
+`BaseStorage` already mixes several concerns:
+- entity / verb CRUD primitives
+- generational record hooks (8.0 MVCC)
+- type-statistics tracking
+- count persistence
+- multi-process safety (new)
+
+Adapters that have no notion of multi-process semantics — `MemoryStorage`,
+cloud adapters (S3, GCS, R2, Azure, OPFS) — still carry seven inherited
+no-ops on their prototype chain. A reader can't tell from the class
+declaration whether a given adapter participates in the locking protocol;
+it has to call `supportsMultiProcessLocking()` and trust the answer.
+
+A cleaner separation:
+
+```typescript
+interface MultiProcessSafeStorage {
+  supportsMultiProcessLocking(): boolean
+  acquireWriterLock(opts?: { force?: boolean }): Promise<WriterLockInfo | null>
+  releaseWriterLock(): Promise<void>
+  readWriterLock(): Promise<WriterLockInfo | null>
+  startFlushRequestWatcher(cb: () => Promise<void>): void
+  stopFlushRequestWatcher(): void
+  requestFlushOverFilesystem(timeoutMs: number): Promise<boolean>
+}
+
+function isMultiProcessSafe(s: BaseStorage): s is BaseStorage & MultiProcessSafeStorage {
+  return typeof (s as any).supportsMultiProcessLocking === 'function'
+    && (s as any).supportsMultiProcessLocking()
+}
+```
+
+Brainy's call sites become:
+
+```typescript
+if (this.config.mode !== 'reader' && isMultiProcessSafe(this.storage)) {
+  await this.storage.acquireWriterLock({ force: this.config.force })
+  // ... TypeScript narrows the rest correctly ...
+}
+```
+
+Benefits:
+- Type system enforces the capability — no more `(this.storage as any).X()`.
+- Adapters that opt out (memory, cloud) are visibly clean.
+- `hasStorageMethod()` defensive helper can stay (still guards
+  build/install artifacts) but doesn't carry the conceptual weight of
+  "did the plugin implement the interface."
+- ADR-style trail for future capability additions: each new capability
+  gets its own interface, opted into explicitly.
+
+## The case against doing it now
+
+- Breaking change for any adapter that already overrides these methods.
+  `FileSystemStorage` is the only one in-tree, but Cor's
+  `MmapFileSystemStorage` inherits from it — interface relocation would
+  ripple through the plugin ecosystem.
+- The current state works. The real failure modes seen in the field
+  were build/install artifacts, not type-system failures.
+- 7.22.0 just shipped a clean fix. Stacking another refactor before
+  consumers absorb it adds churn without urgency.
+- The `hasStorageMethod()` guard accomplishes the same runtime safety the
+  interface narrowing would in TypeScript-aware code.
+
+## Recommendation
+
+**Defer.** Keep the current architecture through the 7.x line. Revisit
+when:
+- A second multi-process capability lands (e.g. distributed-readers
+  coordination) and the natural surface area is more than seven
+  methods. Five+ becomes the moment a separate interface earns its
+  keep.
+- A v8 major is on the table for unrelated reasons. Bundle the
+  interface extraction with that release so consumers absorb both
+  changes in one upgrade.
+
+Until then:
+- Document the inheritance contract (done — see
+  [`concepts/storage-adapters`](../concepts/storage-adapters.md)).
+- Keep `hasStorageMethod()` as the runtime guard.
+- Don't add new methods to `BaseStorage` defaults without re-evaluating
+  the surface-area boundary.
+
+## Migration sketch (when we do it)
+
+For reference, a clean migration path:
+
+1. Add `MultiProcessSafeStorage` interface to `src/storage/coreTypes.ts`.
+2. Move the seven method signatures from `BaseStorage` to the new
+   interface. Default implementations stay on `BaseStorage` but only as
+   private helpers consumed by `FileSystemStorage`'s explicit
+   implementations.
+3. `FileSystemStorage implements MultiProcessSafeStorage` becomes
+   explicit; methods get the `public` modifier with full JSDoc.
+4. Brainy call sites switch from `hasStorageMethod` to
+   `isMultiProcessSafe` type-guard. Keep `hasStorageMethod` for
+   build/install artifact protection.
+5. Document the new contract in `concepts/storage-adapters.md`.
+6. Major-version-bump the `@soulcraft/brainy` peerDep range expected by
+   plugins.
+
+Estimated work: ~half a day of code, ~2 hours of doc/example updates,
+ecosystem coordination via the platform handoff.

docs/architecture/overview.md

@@ -0,0 +1,150 @@
+# Architecture Overview
+
+Brainy is a multi-dimensional AI database that combines vector similarity, graph relationships, and metadata filtering into a unified query system. This document provides a comprehensive overview of the system architecture.
+
+## Core Components
+
+### Brainy (Main Entry Point)
+The central orchestrator that manages all subsystems:
+- **4-Index Architecture**: MetadataIndex, vector index, GraphAdjacencyIndex, DeletedItemsIndex (see [Index Architecture](./index-architecture.md))
+- **Storage System**: FileSystem and Memory adapters
+- **Augmentation System**: Extensible plugin architecture
+- **Triple Intelligence**: Unified query engine
+
+### Triple Intelligence Engine
+Brainy's revolutionary feature that unifies three types of search:
+- **Vector Search**: Semantic similarity via the pluggable vector index
+- **Graph Traversal**: Relationship-based queries
+- **Field Filtering**: Precise metadata filtering with O(1) performance
+
+```typescript
+// Single query combining all three intelligence types
+const results = await brain.find({
+  like: "machine learning papers",              // Vector similarity
+  connected: { to: "research-team", depth: 2 }, // Graph traversal  
+  where: { published: { $gte: "2024-01-01" } }  // Metadata filtering
+})
+```
+
+### Storage Architecture
+
+```
+brainy-data/
+├── _system/           # System management
+│   └── statistics.json
+├── nouns/            # Entity data storage
+│   └── {uuid}.json
+├── metadata/         # Metadata and indexing
+│   ├── {uuid}.json
+│   ├── __entity_registry__.json
+│   └── __metadata_index__*.json
+├── verbs/            # Relationship storage
+└── locks/            # Concurrent access control
+```
+
+### Vector Index
+Pluggable vector index (`VectorIndexProvider`) for efficient nearest-neighbor search. The default JS implementation, `JsHnswVectorIndex`, uses a hierarchical graph:
+- **Performance**: O(log n) search complexity
+- **Configurable recall**: `fast` / `balanced` / `accurate` presets trade recall for latency
+- **Scalable**: Handles millions of vectors per process
+- **Persistent**: Serializable to storage
+- **Swappable**: Replace with a native implementation (such as `@soulcraft/cor`) via the plugin system without changing application code
+
+### Metadata Index Manager
+High-performance field indexing system:
+- **O(1) Lookups**: Inverted index for field→value→IDs mapping
+- **Query Support**: equals, anyOf, allOf, range queries
+- **Chunked Storage**: Supports massive datasets
+- **Auto-indexing**: Automatically maintains indexes on updates
+
+## Performance Characteristics
+
+### Operation Complexity
+- **Vector Search**: O(log n) via the vector index
+- **Field Filtering**: O(1) via inverted indexes
+- **Graph Traversal**: O(V + E) for breadth-first search
+- **Add Operation**: O(log n) for index insertion
+- **Update Operation**: O(1) for metadata updates
+
+### Memory Usage
+- **Base Memory**: ~50MB for core system
+- **Per Vector**: ~1KB (384 dimensions × 4 bytes)
+- **Index Overhead**: ~20% of vector data
+- **Cache Size**: Configurable (default 1000 entries)
+
+### Throughput
+- **Writes**: 1000+ ops/second (with batching)
+- **Reads**: 10,000+ ops/second
+- **Search**: 100+ queries/second (varies by complexity)
+
+## Augmentation System
+
+Brainy's extensible plugin architecture allows for powerful enhancements:
+
+### Core Augmentations
+- **Entity Registry**: High-speed deduplication for streaming data
+- **Batch Processing**: Optimized bulk operations
+- **Request Deduplicator**: Prevents duplicate processing
+
+### Creating Custom Augmentations
+```typescript
+class CustomAugmentation extends BrainyAugmentation {
+  async onInit(brain: Brainy): Promise<void> {
+    // Initialize augmentation
+  }
+  
+  async onAdd(item: any, brain: Brainy): Promise<any> {
+    // Process item before adding
+    return item
+  }
+}
+```
+
+## Caching Strategy
+
+Multi-layered caching for optimal performance:
+- **Search Cache**: LRU cache for query results
+- **Metadata Cache**: Field index caching
+- **Pattern Cache**: NLP pattern matching cache
+- **Entity Cache**: In-memory entity registry
+
+## Integration Points
+
+### Key Objects for Extensions
+- `brain.index`: Access the vector index
+- `brain.metadataIndex`: Access field indexing
+- `brain.graphIndex`: Access graph adjacency index
+- `brain.storage`: Access storage layer
+- `brain.augmentations`: Access augmentation manager
+
+For detailed information about each index, see [Index Architecture](./index-architecture.md).
+
+### Event System
+```typescript
+brain.on('add', (item) => console.log('Item added:', item))
+brain.on('search', (query) => console.log('Search performed:', query))
+brain.on('error', (error) => console.error('Error:', error))
+```
+
+## Best Practices
+
+### When Adding Features
+1. Check if similar functionality exists
+2. Consider if it should be an augmentation
+3. Use existing indexes and caches
+4. Avoid duplicating functionality
+5. Follow the established patterns
+
+### Performance Optimization
+1. Use batch operations for bulk data
+2. Enable appropriate caching
+3. Choose the right storage adapter
+4. Configure index parameters for your use case
+5. Monitor statistics for bottlenecks
+
+## Next Steps
+
+- [Index Architecture](./index-architecture.md) - Deep dive into the 4-index system
+- [Storage Architecture](./storage-architecture.md) - Deep dive into storage system
+- [Triple Intelligence](./triple-intelligence.md) - Advanced query system
+- [API Reference](../api/README.md) - Complete API documentation

docs/architecture/storage-architecture.md

@@ -0,0 +1,318 @@
+# Storage Architecture
+
+> **Updated**: Metadata/vector separation, UUID-based sharding, on-disk artifact for operator-layer backup
+
+## Storage Structure
+
+### Architecture: Metadata/Vector Separation
+
+Entities and relationships are split into **2 separate files** for optimal performance at billion-entity scale:
+
+```
+brainy-data/
+├── _system/                              # System metadata (not sharded)
+│   ├── statistics.json                   # Performance metrics
+│   ├── __metadata_field_index__*.json    # Field indexes
+│   └── __metadata_sorted_index__*.json   # Sorted indexes
+│
+├── entities/
+│   ├── nouns/
+│   │   ├── vectors/                      # Vector graph data (sharded by UUID)
+│   │   │   ├── 00/                       # Shard 00 (first 2 hex digits)
+│   │   │   │   ├── 00123456-....json     # Vector + graph connections
+│   │   │   │   └── 00abcdef-....json
+│   │   │   ├── 01/ ... ff/               # 256 shards total
+│   │   │
+│   │   └── metadata/                     # Business data (sharded by UUID)
+│   │       ├── 00/
+│   │       │   ├── 00123456-....json     # Entity metadata only
+│   │       │   └── 00abcdef-....json
+│   │       ├── 01/ ... ff/
+│   │
+│   └── verbs/
+│       ├── vectors/                      # Relationship vectors (sharded)
+│       │   ├── 00/ ... ff/
+│       │
+│       └── metadata/                     # Relationship data (sharded)
+│           ├── 00/ ... ff/
+```
+
+### Why Split Metadata and Vectors?
+
+**Performance at scale:**
+- **Vector search operations**: Only load vectors (4KB) during search, not metadata (2-10KB)
+- **Filtering**: Only load metadata during filtering, not vectors
+- **Pagination**: Load metadata IDs first, fetch vectors/metadata on-demand
+- **Result**: 60-70% reduction in I/O for typical queries at million-entity scale
+
+### UUID-Based Sharding (256 Shards)
+
+**How it works:**
+```typescript
+const uuid = "3fa85f64-5717-4562-b3fc-2c963f66afa6"
+const shard = uuid.substring(0, 2) // "3f"
+
+// Vector path:   entities/nouns/vectors/3f/3fa85f64-....json
+// Metadata path: entities/nouns/metadata/3f/3fa85f64-....json
+```
+
+**Benefits:**
+- **Uniform distribution**: ~3,900 entities per shard (at 1M scale)
+- **Filesystem optimization**: avoids huge flat directories that bog down `readdir`
+- **Parallel operations**: walk 256 shards in parallel
+- **Predictable**: Deterministic shard assignment
+
+## Storage Adapters
+
+Brainy 8.0 ships two adapters, both implementing the same `StorageAdapter` interface:
+
+### FileSystem Storage (Node.js, default)
+```typescript
+const brain = new Brainy({
+  storage: {
+    type: 'filesystem',
+    path: './data'
+  }
+})
+```
+- **Use case**: Server applications, CLI tools, single-node deployments
+- **Performance**: Direct file I/O
+- **Persistence**: Permanent on disk
+- **Features**:
+  - **Batch Delete**: Efficient bulk deletion with retries
+  - **UUID Sharding**: Automatic 256-shard distribution
+
+### Memory Storage
+```typescript
+const brain = new Brainy({
+  storage: {
+    type: 'memory'
+  }
+})
+```
+- **Use case**: Tests, ephemeral workloads, single-process caches
+- **Performance**: No I/O — all data lives in process memory
+- **Persistence**: None — data is lost when the process exits
+
+### Auto
+```typescript
+const brain = new Brainy({
+  storage: {
+    type: 'auto',
+    path: './data'
+  }
+})
+```
+`'auto'` picks `'filesystem'` when running on Node.js with a writable `path`, and falls back to `'memory'` otherwise.
+
+## Backup and Off-Site Replication
+
+Brainy 8.0 does not embed cloud SDKs. The on-disk artifact at `path` is a plain directory tree of JSON files, so backup is an operator-layer concern. Typical patterns:
+
+- `gsutil rsync -r ./data gs://my-bucket/brainy-data`
+- `aws s3 sync ./data s3://my-bucket/brainy-data`
+- `rclone sync ./data remote:brainy-data`
+- Periodic `tar` snapshots to any object store
+
+Run these from your scheduler (cron, systemd timer, k8s CronJob) — Brainy itself only reads and writes the local directory.
+
+## Metadata Indexing System
+
+### Field Discovery Index
+Tracks all unique values for each field:
+
+```json
+// __metadata_field_index__field_category.json
+{
+  "values": {
+    "technology": 45,
+    "science": 32,
+    "business": 28
+  },
+  "lastUpdated": 1699564234567
+}
+```
+
+### Value-Based Indexes
+Maps field+value combinations to entity IDs:
+
+```json
+// __metadata_index__category_technology_chunk0.json
+{
+  "field": "category",
+  "value": "technology",
+  "ids": ["uuid1", "uuid2", "uuid3", ...],
+  "chunk": 0,
+  "total": 45
+}
+```
+
+### Index Chunking
+Large indexes automatically chunk for performance:
+- **Chunk size**: 10,000 IDs per chunk
+- **Auto-splitting**: Transparent to queries
+- **Parallel loading**: Chunks load on demand
+
+## Entity Registry
+
+High-performance deduplication system for streaming data:
+
+### Registry Structure
+```json
+// __entity_registry__.json
+{
+  "mappings": {
+    "did:plc:alice123": "550e8400-e29b-41d4-a716-446655440000",
+    "handle:alice.bsky.social": "550e8400-e29b-41d4-a716-446655440000"
+  },
+  "stats": {
+    "totalMappings": 10000,
+    "lastSync": 1699564234567
+  }
+}
+```
+
+### Performance Characteristics
+- **Lookup**: O(1) in-memory hash map
+- **Persistence**: Configurable (memory/storage/hybrid)
+- **Cache**: LRU with configurable TTL
+- **Sync**: Periodic or on-demand
+
+## Durability
+
+Brainy persists writes to disk through the filesystem adapter. Each save is a rename-based atomic write of a JSON file under the appropriate shard. Operators that need point-in-time recovery should snapshot `path` (see [Backup and Off-Site Replication](#backup-and-off-site-replication)).
+
+## Storage Optimization
+
+### 1. Batch Operations
+
+```typescript
+// Efficient batch delete
+await storage.batchDelete([
+  'entities/nouns/vectors/00/00123456-....json',
+  'entities/nouns/metadata/00/00123456-....json'
+  // ...
+])
+
+// Batch writes for performance
+await brain.addBatch([
+  { content: "item1", metadata: {} },
+  { content: "item2", metadata: {} },
+  { content: "item3", metadata: {} }
+])
+// Single transaction, optimized I/O
+```
+
+### 2. Caching Strategy
+
+```typescript
+// Configure caching
+const brain = new Brainy({
+  storage: {
+    type: 'filesystem',
+    path: './data',
+    cache: {
+      enabled: true,
+      maxSize: 1000,   // Maximum cached items
+      ttl: 300000,     // 5 minutes
+      strategy: 'lru'  // Least recently used
+    }
+  }
+})
+```
+
+## Concurrent Access
+
+### Locking Mechanism
+```typescript
+// Automatic locking for write operations
+await brain.storage.withLock('resource-id', async () => {
+  // Exclusive access to resource
+  await brain.storage.saveNoun(id, data)
+})
+```
+
+### Read-Write Separation
+- **Reads**: Non-blocking, parallel
+- **Writes**: Serialized with locks
+- **Hybrid**: Read-heavy optimization
+
+## Migration and Backup
+
+Backup and restore go through the Db API — see
+[Snapshots & Time Travel](../guides/snapshots-and-time-travel.md) for the full
+recipe book.
+
+### Snapshot (backup)
+```typescript
+// Instant, self-contained snapshot (hard links on filesystem storage)
+const db = brain.now()
+await db.persist('/backups/2026-06-11')
+await db.release()
+```
+
+### Restore
+```typescript
+// Replace the store's entire state from a snapshot (destructive — confirm required)
+await brain.restore('/backups/2026-06-11', { confirm: true })
+```
+
+### Move to a new directory
+```typescript
+// A snapshot directory is a complete store: restore it into a fresh brain
+const brain = new Brainy({ storage: { type: 'filesystem', path: './new' } })
+await brain.init()
+await brain.restore('/backups/2026-06-11', { confirm: true })
+```
+
+## Performance Tuning
+
+### FileSystem Optimizations
+- **Directory sharding**: 256 shards spread files across subdirectories
+- **Async I/O**: Non-blocking file operations
+- **Buffer pooling**: Reuse buffers for efficiency
+
+### Monitoring
+
+```typescript
+// Get storage statistics
+const stats = await brain.storage.getStatistics()
+console.log(stats)
+// {
+//   totalSize: 1048576,
+//   entityCount: 1000,
+//   indexSize: 204800,
+//   walSize: 10240,
+//   cacheHitRate: 0.85
+// }
+```
+
+## Best Practices
+
+### Choose the Right Adapter
+1. **Development & tests**: `memory` for speed, `filesystem` when you need persistence
+2. **Single-process production**: `filesystem` with off-site backup via `gsutil` / `aws s3 sync` / `rclone`
+3. **Horizontal scaling**: Brainy runs in one process — there is no built-in cluster. Run independent instances behind a service layer and replicate the on-disk artifact with your operator tooling; or run many reader processes against one shared store with a single writer
+
+### Optimize for Your Use Case
+1. **Read-heavy**: Enable caching and let the OS page cache do its job
+2. **Write-heavy**: Batch operations and tune the cache `maxSize`
+3. **Real-time**: FileSystem with periodic snapshots
+4. **Archival**: Snapshot `path` to cold object storage on a schedule
+5. **Large-scale**: Rely on metadata/vector separation + UUID sharding
+
+### Monitor and Maintain
+1. Regular statistics collection
+2. Watch disk usage and shard balance
+3. Index optimization
+4. Cache tuning based on hit rates
+5. Verify backup runs (test restore quarterly)
+
+## API Reference
+
+See the [Storage API](../api/storage.md) for complete method documentation.
+
+---
+
+**Last Updated**: 2026
+**Key Features**: Metadata/vector separation, UUID sharding, filesystem-and-memory adapters, operator-layer backup

docs/architecture/triple-intelligence.md

@@ -0,0 +1,372 @@
+---
+title: Triple Intelligence
+slug: concepts/triple-intelligence
+public: true
+category: concepts
+template: concept
+order: 1
+description: Unified vector similarity, graph traversal, and metadata filtering in one query. Auto-optimizes between parallel execution and progressive filtering.
+next:
+  - concepts/noun-types
+  - api/reference
+---
+
+# Triple Intelligence System
+
+The Triple Intelligence System is Brainy's revolutionary query engine that unifies vector similarity, graph relationships, and metadata filtering into a single, optimized query interface.
+
+## Overview
+
+Traditional databases force you to choose between vector search, graph traversal, OR metadata filtering. Brainy combines all three intelligences into one magical API that automatically optimizes execution for maximum performance.
+
+## Query Interface
+
+### Unified Query Structure
+
+`find()` accepts a single `FindParams` object (or a natural-language string). One
+object combines all three intelligences:
+
+```typescript
+interface FindParams {
+  // Vector intelligence — semantic similarity
+  query?: string                 // Natural-language / semantic query (embedded, matched via HNSW + text index)
+  vector?: number[]              // Pre-computed embedding for direct vector search
+
+  // Metadata intelligence — structured field filters
+  type?: NounType | NounType[]   // Filter by entity type
+  subtype?: string | string[]    // Filter by per-product subtype
+  where?: Record<string, any>    // Field predicates with bare operators (gte, lt, in, contains, exists…)
+
+  // Graph intelligence — relationship traversal
+  connected?: {
+    to?: string                  // Reachable to this entity
+    from?: string                // Reachable from this entity
+    via?: VerbType | VerbType[]  // Relationship type(s) to traverse (alias: type)
+    depth?: number               // Max traversal depth (default: 1)
+    direction?: 'in' | 'out' | 'both'
+  }
+
+  // Proximity — nearest neighbours of a known entity
+  near?: { id: string; threshold?: number }
+
+  // Control
+  limit?: number                 // Max results (default: 10)
+  offset?: number                // Skip N results
+  orderBy?: string               // Field to sort by (e.g. 'createdAt')
+  order?: 'asc' | 'desc'         // Sort direction
+}
+```
+
+### Example Queries
+
+#### Natural Language Queries with find()
+```typescript
+// Brainy understands natural language and extracts intent
+const results = await brain.find("research papers about neural networks from 2023")
+// Automatically interprets: document type, topic, time range
+
+// Complex temporal and numeric queries
+const reports = await brain.find("quarterly reports from Q3 2024 with revenue over 10M")
+// Automatically extracts: report type, date range, numeric filters
+
+// Multi-condition natural language
+const articles = await brain.find("verified articles by John Smith about machine learning published this year")
+// Automatically identifies: author, topic, verification status, time range
+```
+
+#### Simple Vector Search
+```typescript
+const results = await brain.find("machine learning concepts")
+```
+
+#### Combined Intelligence Query
+```typescript
+const results = await brain.find({
+  query: "neural networks",
+  where: {
+    category: "research",
+    year: { gte: 2023 }
+  },
+  connected: {
+    to: "deep-learning-team",
+    depth: 2
+  },
+  limit: 20
+})
+```
+
+## Query Optimization
+
+### Automatic Plan Generation
+
+The Triple Intelligence engine analyzes each query to create an optimal execution plan:
+
+1. **Selectivity Analysis**: Identifies the most selective filters
+2. **Cost Estimation**: Estimates computational cost for each operation
+3. **Strategy Selection**: Chooses between parallel or progressive execution
+4. **Plan Caching**: Caches successful plans for similar queries
+
+### Execution Strategies
+
+#### Parallel Execution
+All three search types execute simultaneously:
+- **Best for**: Balanced queries with multiple signals
+- **Performance**: Maximum speed through parallelization
+- **Use case**: Complex queries needing all intelligence types
+
+```typescript
+// Parallel execution for balanced query
+const results = await brain.find({
+  query: "AI research",          // ~1000 potential matches
+  where: { kind: "paper" },       // ~500 potential matches
+  connected: { to: "stanford" }   // ~200 potential matches
+})
+// All three execute in parallel, results fused
+```
+
+#### Progressive Filtering
+Operations chain for maximum efficiency:
+- **Best for**: Queries with highly selective filters
+- **Performance**: Reduces search space at each step
+- **Use case**: Large datasets with specific criteria
+
+```typescript
+// Progressive execution for selective query
+const results = await brain.find({
+  where: { userId: "user123" },   // Very selective (1-10 matches)
+  query: "recent posts",           // Applied to filtered set
+  limit: 5
+})
+// Metadata filter first, then vector search on results
+```
+
+## Fusion Ranking
+
+### Score Combination
+
+When multiple intelligence types return results, scores are intelligently combined:
+
+```typescript
+fusionScore = (
+  vectorScore * vectorWeight +    // Semantic relevance (0.4)
+  graphScore * graphWeight +      // Relationship strength (0.3)
+  fieldScore * fieldWeight        // Exact match confidence (0.3)
+) / totalWeight
+```
+
+### Adaptive Weights
+
+Weights adjust based on query characteristics:
+- **Text-heavy query**: Higher vector weight
+- **Relationship query**: Higher graph weight  
+- **Specific filters**: Higher field weight
+
+## Natural Language Processing
+
+### Pattern Recognition
+
+Brainy includes 220+ embedded patterns for natural language understanding:
+
+```typescript
+// Natural language automatically parsed
+const results = await brain.find(
+  "show me recent AI papers from Stanford published this year"
+)
+// Automatically converts to:
+// {
+//   query: "AI papers",
+//   where: {
+//     institution: "Stanford",
+//     published: { gte: "2024-01-01" }
+//   }
+// }
+```
+
+### Intent Detection
+
+The NLP processor identifies query intent:
+- **Informational**: "what is", "how does"
+- **Navigational**: "find", "show me"
+- **Transactional**: "create", "update"
+- **Analytical**: "compare", "analyze"
+
+## Performance Optimization
+
+### Query Plan Caching
+
+Successful execution plans are cached:
+```typescript
+// First call parses the natural-language query and builds an execution plan
+await brain.find("machine learning papers")
+
+// A structurally similar query reuses that plan, skipping plan generation
+await brain.find("deep learning papers")
+```
+
+### Self-Optimization
+
+Brainy uses itself to optimize queries:
+- Query patterns stored in separate brain instance
+- Execution times tracked and analyzed
+- Plans automatically improved based on performance
+
+### Index Utilization
+
+Triple Intelligence leverages all available indexes:
+- **HNSW Index**: For vector similarity
+- **Metadata Index**: For metadata filtering
+- **Graph Index**: For relationship traversal
+
+## Advanced Features
+
+### Explain Mode
+
+Diagnose how a query's `where` fields map to the index. Run `brain.explain()`
+first whenever `find()` returns surprising or empty results:
+
+```typescript
+const plan = await brain.explain({
+  query: "quantum computing",
+  where: { category: "research" }
+})
+
+console.log(plan.fieldPlan)
+// [
+//   { field: 'category', path: 'column-store', notes: '...' }
+// ]
+
+console.log(plan.warnings)
+// e.g. ['Field "category" has no index entries. find() will return [] silently...']
+```
+
+### Result Ordering
+
+Sort results by any stored field with `orderBy` / `order`:
+
+```typescript
+const results = await brain.find({
+  query: "news articles",
+  where: { verified: true },
+  orderBy: 'createdAt',  // Newest first
+  order: 'desc'
+})
+```
+
+### Similarity Threshold
+
+Find the nearest neighbours of a known entity and keep only close matches with
+`near`:
+
+```typescript
+const results = await brain.find({
+  near: { id: anchorId, threshold: 0.9 },  // Only results >= 0.9 similarity
+  limit: 10
+})
+```
+
+## Best Practices
+
+### Query Design
+
+1. **Start specific**: Use selective filters when possible
+2. **Combine intelligently**: Don't force all three types if not needed
+3. **Use limits**: Always specify reasonable result limits
+4. **Cache results**: For repeated queries, cache at application level
+
+### Performance Tips
+
+1. **Index first**: Ensure fields used in `where` clauses are indexed
+2. **Batch operations**: Use batch methods for bulk queries
+3. **Monitor plans**: Use explain mode to understand performance
+4. **Optimize patterns**: Train custom patterns for your domain
+
+### Common Patterns
+
+#### Semantic Search with Filtering
+```typescript
+// Find similar content with constraints
+const results = await brain.find({
+  query: searchText,
+  where: {
+    status: 'published',
+    language: 'en'
+  }
+})
+```
+
+#### Related Items Discovery
+```typescript
+// Find items related to a specific item
+const results = await brain.find({
+  connected: {
+    to: itemId,
+    depth: 2,
+    via: VerbType.RelatedTo
+  },
+  limit: 20
+})
+```
+
+#### Time-based Queries
+```typescript
+// Recent items matching criteria
+const results = await brain.find({
+  where: {
+    timestamp: { gte: Date.now() - 86400000 }
+  },
+  query: "trending topics",
+  orderBy: 'timestamp',
+  order: 'desc'
+})
+```
+
+## Natural Language Processing
+
+The `find()` method includes advanced NLP capabilities powered by 220+ embedded patterns that understand natural language queries.
+
+### Supported Query Types
+
+```typescript
+// Temporal queries
+await brain.find("documents from last week")
+await brain.find("reports created yesterday")
+await brain.find("articles published in Q3 2024")
+await brain.find("data from January to March")
+
+// Numeric filters
+await brain.find("products with price under $100")
+await brain.find("articles with more than 1000 views")
+await brain.find("reports showing revenue over 10M")
+
+// Combined conditions
+await brain.find("verified research papers about AI from 2024 with high citations")
+await brain.find("recent customer reviews with rating above 4 stars")
+await brain.find("blog posts by John Smith about machine learning published this month")
+
+// Relationship queries
+await brain.find("documents related to project X")
+await brain.find("people who work at TechCorp")
+await brain.find("products similar to iPhone")
+```
+
+### How It Works
+
+1. **Intent Detection**: Identifies what the user is looking for
+2. **Entity Extraction**: Extracts names, dates, numbers, categories
+3. **Temporal Parsing**: Converts "last week", "Q3 2024" to date ranges
+4. **Filter Generation**: Creates appropriate where clauses
+5. **Query Fusion**: Combines NLP understanding with vector search
+
+### Pattern Coverage
+
+Brainy includes 220+ pre-computed patterns covering:
+- **Temporal**: 40+ patterns for dates and time ranges
+- **Numeric**: 30+ patterns for comparisons and ranges
+- **Relationships**: 25+ patterns for connections
+- **Actions**: 35+ patterns for verbs and intents
+- **Entities**: 40+ patterns for people, places, things
+- **Domain-specific**: 50+ patterns for tech, business, social
+
+## API Reference
+
+See the [Triple Intelligence API](../api/triple-intelligence.md) for complete method documentation.

docs/architecture/zero-config.md

@@ -0,0 +1,157 @@
+---
+title: Zero Configuration
+slug: concepts/zero-config
+public: false
+category: concepts
+template: concept
+order: 3
+description: Brainy auto-detects storage, initializes embeddings, and builds indexes — no configuration required. Works in Node.js and Bun (server-only since 8.0).
+next:
+  - getting-started/installation
+  - guides/storage-adapters
+---
+
+# Zero Configuration & Auto-Adaptation
+
+> **"Zero config by default, fully tunable when you need it."** Construct a
+> `Brainy()` with no options and it picks sensible, environment-aware defaults.
+> Every default below is overridable through the constructor — see the
+> [API Reference](../api/README.md#configuration).
+
+## Overview
+
+Brainy 8.0 is server-only (Node.js 22+ / Bun). With no configuration it:
+
+- selects a storage adapter from the runtime,
+- initializes the embedding model (all-MiniLM-L6-v2, 384 dimensions),
+- builds and maintains the metadata, graph, and vector indexes,
+- sizes its caches and write buffers to the detected memory budget,
+- chooses a persistence mode that matches the storage backend, and
+- quiets its own logging when it detects a production environment.
+
+There is no public config-generation function — adaptation happens inside the
+constructor and `init()`.
+
+## Instant Start
+
+```typescript
+import { Brainy } from '@soulcraft/brainy'
+
+// That's it. No config needed.
+const brain = new Brainy()
+await brain.init()
+
+await brain.add({ data: 'First entity', type: 'concept' })
+const results = await brain.find('first')
+```
+
+## What Auto-Adaptation Covers
+
+### 1. Storage auto-detection
+
+With no `storage` option, Brainy uses `type: 'auto'`:
+
+- **Filesystem** when running on a runtime with a writable Node filesystem and a
+  resolvable root directory. This is the default for typical Node/Bun servers and
+  persists across restarts.
+- **In-memory** otherwise (no filesystem access, or an explicit memory request).
+  Fast, zero I/O, discarded on process exit — ideal for tests and ephemeral
+  caches.
+
+8.0 ships exactly two storage adapters — `memory` and `filesystem` — plus the
+`auto` selector that resolves to one of them. See
+[Storage Adapters](../concepts/storage-adapters.md) for the full contract.
+
+```typescript
+// Explicit override when you want a specific root
+const brain = new Brainy({
+  storage: { type: 'filesystem', path: './brainy-data' }
+})
+```
+
+### 2. HNSW quality from the `recall` preset
+
+Vector-index quality comes from a single preset rather than hand-tuned graph
+parameters. `config.vector.recall` accepts `'fast'`, `'balanced'`, or
+`'accurate'` and defaults to `'balanced'`. The preset maps internally to the
+HNSW construction and search parameters (`M` / `efConstruction` / `efSearch`),
+so you trade recall against latency with one knob instead of three.
+
+```typescript
+const brain = new Brainy({
+  vector: { recall: 'fast' } // favor latency over recall
+})
+```
+
+The default JS index is `JsHnswVectorIndex`. An optional native acceleration
+provider (the `@soulcraft/cor` package) can replace it with a
+higher-performing implementation; the public knobs stay the same. Quantization
+and other index-internal acceleration are the native provider's concern, not a
+Brainy configuration option.
+
+### 3. Persistence mode follows the backend
+
+`config.vector.persistMode` accepts `'immediate'` or `'deferred'`. Left unset,
+Brainy chooses for you:
+
+- **Immediate** on filesystem storage, so the index file stays in lock-step with
+  the data and survives a crash.
+- **Deferred** on in-memory storage, where there is nothing durable to sync to,
+  so writes are batched for throughput.
+
+```typescript
+const brain = new Brainy({
+  vector: { persistMode: 'deferred' } // batch persistence for write-heavy loads
+})
+```
+
+### 4. Memory-aware cache and buffer sizing
+
+Brainy reads the container's memory budget — `CLOUD_RUN_MEMORY`, `MEMORY_LIMIT`,
+or the cgroup memory limit when running in a container — and sizes its read
+caches and write buffers to fit. On a small instance it stays conservative; on a
+large one it uses more of the available headroom. Query-result limits are capped
+against the same budget (roughly 25 KB per result) to keep a single oversized
+query from exhausting memory.
+
+You can pin the cache explicitly:
+
+```typescript
+const brain = new Brainy({
+  cache: { maxSize: 10000, ttl: 3_600_000 }
+})
+```
+
+### 5. Logging quiets in production
+
+Brainy detects production-style environments (for example `NODE_ENV` set to a
+non-development value) and reduces its own log verbosity automatically. This is
+logging-only behavior — it does not change indexing, storage, or query results.
+
+## Configuration Override
+
+Zero-config is the default, not a ceiling. Every adaptive decision above has an
+explicit constructor option:
+
+```typescript
+const brain = new Brainy({
+  storage: { type: 'filesystem', path: '/var/lib/brainy' },
+  vector: {
+    recall: 'accurate',
+    persistMode: 'immediate'
+  },
+  cache: { maxSize: 50000, ttl: 600_000 }
+})
+
+await brain.init()
+```
+
+See the [API Reference](../api/README.md#configuration) for the complete option
+list.
+
+## See Also
+
+- [Architecture Overview](./overview.md)
+- [Storage Adapters](../concepts/storage-adapters.md)
+- [Scaling Guide](../SCALING.md)
+- [API Reference](../api/README.md)