.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
+node_modules/
-/cloud-wrapper/node_modules
 npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
-/.pnp
-.pnp.js
 
-# Coverage directory
+# Build outputs
-/coverage
+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
+*.swp
-*.iws
+*.swo
-*.ipr
+*~
-*.sublime-workspace
-*.sublime-project
 
 # OS files
 .DS_Store
 Thumbs.db
 
-# Data directories created by FileSystemStorage
+# Temporary files
-/brainy-data
+tmp/
-/custom-data
+temp/
-/clean-history.sh
+*.tmp
-/bluesky-augmentation/node_modules/
-/bluesky-augmentation/dist/
 
-# Test files
+# Planning and instruction files
-/test-worker.js
+plan.md
-/test-node24-worker.js
-/test-results.json
-/tests/results/
-/tests/results/*.json
 
-# Generated files
+# Package files
-/encoded-image.html
+*.tgz
-/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/
 
-# Temporary test files created by AI agents
+# Private/confidential files
-test*.js
+PLAN.md
-test*.ts
+INTERNAL_NOTES.md
-temp-test*.js
+TODO_PRIVATE.md
-temp-test*.ts
+*.tar.gz
-reproduction*.js
+
-reproduction*.ts
+# Strategy and planning documents (private)
-debug*.js
+.strategy/
-debug*.ts
+# Removed: PRODUCTION_*.md (now these should be public documentation)
-/temp/
+DISTRIBUTED_*.md
-/temp-tests/
+*_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
+# Source files (not needed in package)
-*.map
-**/*.map
-
-# Development files
-node_modules/
 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
+.gitignore
-.prettierrc
+.npmignore
-tsconfig*.json
+tsconfig.json
-rollup.config.js
+vitest.config.ts
-jest.config.js
+vitest.config.mts
+*.config.js
+*.config.ts
+.eslintrc*
+.prettierrc*
 
-# Build artifacts
+# Test files
-emocoverage/
+test-*.js
-.nyc_output/
+test-*.ts
+*.test.ts
+*.test.js
+*.spec.ts
+*.spec.js
 
-# Large files
+# Temporary and log files
-# Include the logo but exclude other PNGs
-!brainy.png
-*.png
-encoded-image.*
-README.demo.md
-scalingStrategy.md
-
-# Misc
-.DS_Store
 *.log
-npm-debug.log*
+*.tmp
-yarn-debug.log*
+tmp/
-yarn-error.log*
+temp/
-test-results.json
+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

.versionrc.json

@@ -1,22 +0,0 @@
-{
-  "types": [
-    {"type": "feat", "section": "Added", "hidden": false},
-    {"type": "fix", "section": "Fixed", "hidden": false},
-    {"type": "chore", "section": "Changed", "hidden": false},
-    {"type": "docs", "section": "Documentation", "hidden": false},
-    {"type": "style", "section": "Changed", "hidden": true},
-    {"type": "refactor", "section": "Changed", "hidden": false},
-    {"type": "perf", "section": "Changed", "hidden": false},
-    {"type": "test", "section": "Tests", "hidden": true},
-    {"type": "build", "section": "Build System", "hidden": true},
-    {"type": "ci", "section": "Continuous Integration", "hidden": true}
-  ],
-  "releaseCommitMessageFormat": "chore(release): {{currentTag}} [skip ci]",
-  "commitUrlFormat": "https://github.com/soulcraft-research/brainy/commit/{{hash}}",
-  "compareUrlFormat": "https://github.com/soulcraft-research/brainy/compare/{{previousTag}}...{{currentTag}}",
-  "issueUrlFormat": "https://github.com/soulcraft-research/brainy/issues/{{id}}",
-  "userUrlFormat": "https://github.com/{{user}}",
-  "skip": {
-    "tag": false
-  }
-}

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.

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
+## Where the project lives
-contributing to the project.
 
-We welcome contributions of all kinds, including bug fixes, feature additions, documentation improvements, and more.
+The source of truth is a self-hosted forge: **source.soulcraft.com/soulcraft/brainy**.
-By participating in this project, you agree to abide by our [Code of Conduct](CODE_OF_CONDUCT.md).
+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
+**Found a bug, or have an idea?** Email **brainy@soulcraft.com**. No account,
-changes. Good commit messages help maintainers understand your contributions and make the review process smoother.
+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)
+- **Email a patch.** Run `git format-patch` against your change and email the
-- Use the imperative mood ("Add feature" not "Added feature")
+  output to **brainy@soulcraft.com**. This is a genuinely supported path, not
-- Reference issues and pull requests where appropriate
+  a fallback — plenty of good contributions arrive this way.
-- When necessary, provide more detailed explanations in the commit body
+- **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.
 
-```
+## Development setup
-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:
 
 ```bash
-npm run lint         # Run ESLint to check for code issues
+git clone https://source.soulcraft.com/soulcraft/brainy.git
-npm run lint:fix     # Automatically fix linting issues
+cd brainy
-npm run format       # Format your code with Prettier
+npm install
-npm run check-format # Check if your code is properly formatted
+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
+## Standards
-- `develop` - The development branch contains the latest development changes
-- Feature branches - Create a branch from `develop` for your feature or fix
 
-When working on a new feature or fix:
+- **Strict TypeScript.** No `any` escape hatches to dodge the type checker.
-1. Create a new branch from `develop` with a descriptive name (e.g., `feature/add-vector-normalization` or `fix/distance-calculation`)
+- **Tests exercise real behavior.** No mocking away the thing you're supposed
-2. Make your changes in that branch
+  to be testing.
-3. Submit a pull request to merge your branch into `develop`
+- **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
+Thank you for considering a contribution.
-- 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!

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"]

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.

README_updates.md

@@ -1,110 +0,0 @@
-## Recent Changes and Performance Improvements
-
-### Enhanced Memory Management and Scalability
-
-Brainy has been significantly improved to handle larger datasets more efficiently:
-
-- **Pagination Support**: All data retrieval methods now support pagination to avoid loading entire datasets into memory at once. The deprecated `getAllNouns()` and `getAllVerbs()` methods have been replaced with `getNouns()` and `getVerbs()` methods that support pagination, filtering, and cursor-based navigation.
-
-- **Multi-level Caching**: A sophisticated three-level caching strategy has been implemented:
-  - **Level 1**: Hot cache (most accessed nodes) - RAM (automatically detecting and adjusting in each environment)
-  - **Level 2**: Warm cache (recent nodes) - OPFS, Filesystem or S3 depending on environment
-  - **Level 3**: Cold storage (all nodes) - OPFS, Filesystem or S3 depending on environment
-
-- **Adaptive Memory Usage**: The system automatically detects available memory and adjusts cache sizes accordingly:
-  - In Node.js: Uses 10% of free memory (minimum 1000 entries)
-  - In browsers: Scales based on device memory (500 entries per GB, minimum 1000)
-
-- **Intelligent Cache Eviction**: Implements a Least Recently Used (LRU) policy that evicts the oldest 20% of items when the cache reaches the configured threshold.
-
-- **Prefetching Strategy**: Implements batch prefetching to improve performance while avoiding overwhelming system resources.
-
-### S3-Compatible Storage Improvements
-
-- **Enhanced Cloud Storage**: Improved support for S3-compatible storage services including AWS S3, Cloudflare R2, and others.
-
-- **Optimized Data Access**: Batch operations and error handling for efficient cloud storage access.
-
-- **Change Log Management**: Efficient synchronization through change logs to track updates.
-
-### Data Compatibility
-
-Yes, you can use existing data indexed from an old version. Brainy includes robust data migration capabilities:
-
-- **Vector Regeneration**: If vectors are missing in imported data, they will be automatically created using the embedding function.
-
-- **HNSW Index Reconstruction**: The system can reconstruct the HNSW index from backup data, ensuring compatibility with previous versions.
-
-- **Sparse Data Import**: Support for importing sparse data (without vectors) through the `importSparseData()` method.
-
-### System Requirements
-
-#### Default Mode
-
-- **Memory**: 
-  - Minimum: 512MB RAM
-  - Recommended: 2GB+ RAM for medium datasets, 8GB+ for large datasets
-  
-- **CPU**: 
-  - Minimum: 2 cores
-  - Recommended: 4+ cores for better performance with parallel operations
-
-- **Storage**:
-  - Minimum: 1GB available storage
-  - Recommended: Storage space at least 3x the size of your dataset
-
-#### Read-Only Mode
-
-Read-only mode prevents all write operations (add, update, delete) and is optimized for search operations.
-
-- **Memory**: 
-  - Minimum: 256MB RAM
-  - Recommended: 1GB+ RAM
-  
-- **CPU**: 
-  - Minimum: 1 core
-  - Recommended: 2+ cores
-
-- **Storage**:
-  - Minimum: Storage space equal to the size of your dataset
-  - Recommended: 2x the size of your dataset for caching
-
-- **New Feature**: Lazy loading support in read-only mode for improved performance with large datasets.
-
-#### Write-Only Mode
-
-Write-only mode prevents all search operations and is optimized for initial data loading or when you want to optimize for write performance.
-
-- **Memory**: 
-  - Minimum: 512MB RAM
-  - Recommended: 2GB+ RAM
-  
-- **CPU**: 
-  - Minimum: 2 cores
-  - Recommended: 4+ cores for faster data ingestion
-
-- **Storage**:
-  - Minimum: Storage space at least 2x the size of your dataset
-  - Recommended: 4x the size of your dataset for optimal performance
-
-### Performance Tuning Parameters
-
-Brainy offers several configuration options for performance tuning:
-
-- **Hot Cache Size**: Control the maximum number of items to keep in memory.
-- **Eviction Threshold**: Set the threshold at which cache eviction begins (default: 0.8 or 80% of max size).
-- **Warm Cache TTL**: Set the time-to-live for items in the warm cache (default: 24 hours).
-- **Batch Size**: Control the number of items to process in a single batch for operations like prefetching (default: 10).
-
-#### NEW: Automatic Parameter Tuning
-
-These parameters can now be automatically configured and tuned based on:
-
-- **Environment Detection**: Automatically detects the runtime environment (Node.js, browser, worker) and available resources.
-- **Resource Awareness**: Adjusts parameters based on available memory and CPU resources.
-- **Usage Statistics**: Analyzes cache hit/miss ratios and operation patterns to optimize parameters.
-- **Workload Adaptation**: Tunes parameters differently for read-heavy vs. write-heavy workloads.
-
-Auto-tuning is enabled by default but can be disabled by setting `autoTune: false` in the cache configuration. Manual parameter values will always take precedence over auto-tuned values.
-
-These improvements make Brainy more efficient, scalable, and adaptable to different environments and usage patterns.

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.

archive/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.

archive/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.

archive/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.

archive/fix-documentation.md

@@ -1,34 +0,0 @@
-# Fix for "process.memoryUsage is not a function" Error
-
-## 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.

archive/test-issue-summary.md

@@ -1,32 +0,0 @@
-# API Integration Test Issue Resolution
-
-## 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.

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/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/DOCUMENTATION_ORGANIZATION.md

@@ -1,124 +0,0 @@
-# Documentation Organization
-
-This document explains the new documentation structure and workflow for managing markdown files in the Brainy project.
-
-## Overview
-
-The documentation has been reorganized from 29 scattered markdown files at the root level to a clean, organized structure with only essential files at the root and categorized documentation in the `docs/` directory.
-
-## New Structure
-
-### Root Level Files (GitHub/NPM Standards)
-- `README.md` - Main project documentation
-- `CONTRIBUTING.md` - Contribution guidelines  
-- `CODE_OF_CONDUCT.md` - Community standards
-- `CHANGELOG.md` - Version history and release notes
-
-### Documentation Directory Structure
-```
-docs/
-├── technical/           # Technical documentation and analysis
-│   ├── concurrency-analysis.md
-│   ├── storage-concurrency-analysis.md
-│   ├── threading.md
-│   ├── statistics.md
-│   ├── testing.md
-│   ├── vitest-improvements.md
-│   ├── realtime-updates.md
-│   ├── metadata-handling.md
-│   ├── vector-dimension-standardization.md
-│   ├── use-model-loading-explanation.md
-│   ├── dimension-mismatch-summary.md
-│   ├── storage-testing.md
-│   ├── technical-guides.md
-│   └── concurrency-implementation-summary.md
-├── development/         # Development and contributor documentation
-│   ├── developers.md
-│   ├── documentation-standards.md
-│   ├── markdown-conventions.md
-│   ├── expected-test-messages.md
-│   └── pretty-test-reporter.md
-└── guides/             # User guides and migration documentation
-    └── production-migration-guide.md
-```
-
-### Archive Directory
-```
-archive/                # Archived and temporary files
-├── changes.md          # Old detailed changelog
-├── changes-summary.md  # Old changelog summary
-├── demo.md            # Demo documentation
-├── fix-documentation.md # Temporary fix notes
-└── test-issue-summary.md # Test issue summary
-```
-
-## CHANGELOG.md Management
-
-### Automated Workflow
-
-The project now uses automated changelog management:
-
-1. **Adding Changes**: Add entries to the `[Unreleased]` section in `CHANGELOG.md`
-2. **Version Bumping**: Use npm scripts that automatically update the changelog:
-   - `npm run version:patch` - Patch version bump + changelog update
-   - `npm run version:minor` - Minor version bump + changelog update  
-   - `npm run version:major` - Major version bump + changelog update
-
-3. **Manual Updates**: Use `npm run changelog:update` to manually update the changelog
-
-### Changelog Format
-
-The changelog follows the [Keep a Changelog](https://keepachangelog.com/) standard:
-
-- **Added** - New features
-- **Changed** - Changes in existing functionality
-- **Deprecated** - Soon-to-be removed features
-- **Removed** - Now removed features
-- **Fixed** - Bug fixes
-- **Security** - Vulnerability fixes
-
-### GitHub Integration
-
-The CHANGELOG.md is automatically used for:
-- GitHub releases (via `scripts/create-github-release.js`)
-- NPM package release notes
-- Version history tracking
-
-## Benefits of New Structure
-
-1. **Clean Root Directory**: Reduced from 29 to 4 essential markdown files
-2. **Better Organization**: Logical categorization of documentation
-3. **GitHub Compliance**: Follows GitHub and NPM best practices
-4. **Automated Maintenance**: Changelog updates are automated
-5. **Easy Navigation**: Clear directory structure for different doc types
-6. **Historical Preservation**: Old documentation archived, not lost
-
-## Workflow for Contributors
-
-### Adding Documentation
-1. **Technical docs** → `docs/technical/`
-2. **Development docs** → `docs/development/`
-3. **User guides** → `docs/guides/`
-4. **Temporary files** → `archive/` (if needed)
-
-### Making Changes
-1. Add changes to `[Unreleased]` section in `CHANGELOG.md`
-2. Use appropriate category (Added, Changed, Fixed, etc.)
-3. When ready to release, use `npm run version:patch/minor/major`
-4. The changelog will be automatically updated with version and date
-
-### Release Process
-1. Ensure `[Unreleased]` section has all changes
-2. Run `npm run version:patch/minor/major`
-3. Run `npm run deploy` to publish and create GitHub release
-4. GitHub release will use CHANGELOG.md content
-
-## Migration Notes
-
-- All technical documentation moved to `docs/technical/`
-- Development documentation moved to `docs/development/`
-- Old changelog files archived in `archive/`
-- Links in existing documentation may need updates
-- New automation ensures changelog stays current
-
-This reorganization provides a sustainable, scalable approach to documentation management that follows industry best practices and integrates seamlessly with GitHub and NPM workflows.

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)

docs/concepts/consistency-model.md

@@ -0,0 +1,386 @@
+---
+title: Consistency Model
+slug: concepts/consistency-model
+public: true
+category: concepts
+template: concept
+order: 4
+description: The exact guarantees behind Brainy's Db API — snapshot isolation, atomic transactions, two levels of compare-and-swap, time travel, retention, snapshots, crash recovery, and the reserved-field contract.
+next:
+  - guides/snapshots-and-time-travel
+  - guides/optimistic-concurrency
+---
+
+# Consistency Model
+
+Brainy 8.0's consistency story rests on one mechanism: **generational MVCC**
+— multi-version concurrency control over immutable, generation-stamped
+records. It is exposed through a single value type, the **`Db`**: an
+immutable, point-in-time view of the whole store that you query like the
+live brain.
+
+```typescript
+const db = brain.now()                 // pin the current state — O(1), no I/O
+
+await brain.transact([
+  { op: 'update', id: invoiceId, metadata: { status: 'paid' } }
+])
+
+await db.get(invoiceId)                // still 'pending' — pinned, forever
+await brain.get(invoiceId)             // 'paid' — live
+await db.release()                     // unpin when done
+```
+
+This page states the guarantees precisely — what is promised, what it costs,
+and where the honest limits are. The design record is
+[ADR-001](../ADR-001-generational-mvcc.md); every guarantee below is proven
+by a dedicated test in `tests/integration/db-mvcc.test.ts`.
+
+## The generation clock
+
+A **monotonic 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`/…).
+- `brain.generation()` reads it; it is persisted in the data directory and
+  **never reissued** — not across restarts, and not across `restore()`
+  (the counter is floored at its pre-restore value).
+
+Every `Db` is pinned at one generation. `db.generation` and `db.timestamp`
+identify the view; `newerDb.since(olderDb)` returns exactly the entity and
+relationship ids that committed transactions touched between two views.
+
+## Snapshot isolation for reads
+
+**Guarantee:** a `Db` reads exactly the state at its pinned generation, no
+matter what commits afterwards — including deletes. There are no torn reads,
+no partially applied batches, and no drift over time.
+
+- `brain.now()` pins the current generation in O(1).
+- `brain.transact()` returns a `Db` pinned at the freshly committed
+  generation.
+- `brain.asOf(generation | Date | snapshotPath)` pins past state.
+
+While nothing has committed past the pin, reads delegate to the live fast
+paths — pinning is free until history actually moves. Once later
+transactions commit, the view keeps serving the **full query surface** at
+its generation (see "Reading the past" below).
+
+Writers are never blocked by readers and readers never block writers: a
+pinned view stays valid because nothing overwrites the immutable records it
+resolves from (the LMDB reader-pin model).
+
+## Transaction atomicity
+
+`brain.transact(ops)` executes a declarative batch — `add`, `update`,
+`remove`, `relate`, `unrelate` — **atomically as exactly one generation**:
+
+```typescript
+const db = await brain.transact([
+  { op: 'add', id: orderId, type: NounType.Document, subtype: 'order', data: 'Order #1042' },
+  { op: 'add', id: itemId, type: NounType.Thing, subtype: 'line-item', data: 'Widget x3' },
+  { op: 'relate', from: orderId, to: itemId, type: VerbType.Contains, subtype: 'order-line' }
+], { meta: { author: 'order-service', requestId: 'req-9f2' } })
+
+db.receipt.ids   // resolved id per operation, in input order
+```
+
+Either every operation applies, or none do and the store is byte-identical
+to its pre-transaction state. Operation semantics mirror the corresponding
+single-operation methods — validation, subtype enforcement, relationship
+deduplication, delete cascades — and later operations may reference ids
+created earlier in the same batch.
+
+**The commit point is one atomic rename.** The durability protocol:
+
+1. Before-images of every touched id are staged into an immutable
+   generation directory and **fsynced**.
+2. The batch executes through the transaction manager (which has its own
+   operation-level rollback for non-crash failures).
+3. The store manifest is replaced via atomic temp-file rename and fsynced.
+   **The rename is the commit** — a generation is committed if and only if
+   the manifest says so.
+
+**Crash recovery:** on the next open, any staged generation above the
+manifest watermark is an uncommitted transaction; its before-images are
+restored (idempotently — recovery can itself crash and rerun) and derived
+indexes never observe the rolled-back state. A crash anywhere before the
+rename rolls back to the exact pre-transaction bytes; a crash after it keeps
+the transaction.
+
+Transaction metadata (`meta`) is reified Datomic-style: recorded in an
+append-only transaction log readable via `brain.transactionLog()` — audit
+fields live in the database, not in commit messages.
+
+## Two levels of compare-and-swap
+
+Concurrent `transact()` calls commit serially (snapshot-isolated batches).
+For lost-update protection across a read–modify–write cycle, Brainy offers
+CAS at two granularities:
+
+| Granularity | Mechanism | Conflict error | Use when |
+|---|---|---|---|
+| **Per entity** | `_rev` + `{ op: 'update', ifRev }` (also on `brain.update()`) | `RevisionConflictError` | "This entity must not have changed since I read it." |
+| **Whole store** | `transact(ops, { ifAtGeneration })` | `GenerationConflictError` | "*Nothing* may have committed since I read." |
+
+```typescript
+const view = brain.now()
+const order = await view.get(orderId)
+
+try {
+  await brain.transact(
+    [{ op: 'update', id: orderId, metadata: { total: recompute(order) }, ifRev: order._rev }],
+    { ifAtGeneration: view.generation }
+  )
+} catch (err) {
+  if (err instanceof GenerationConflictError) {
+    // Something committed since the pin — re-read and retry.
+  }
+} finally {
+  await view.release()
+}
+```
+
+An `ifRev` conflict on any operation rejects the **whole batch**; an
+`ifAtGeneration` conflict is detected before anything is staged. Both leave
+the store untouched and the generation counter unchanged. See
+[Optimistic concurrency with `_rev`](../guides/optimistic-concurrency.md)
+for the per-entity pattern in depth.
+
+## Reading the past
+
+`brain.asOf()` accepts a generation number, a `Date` (resolved through the
+transaction log to the newest generation committed at or before it), or a
+snapshot directory path. Historical views serve the **full query surface**
+— `get()`, `find()` in every mode, semantic search, graph traversal,
+cursors, aggregation — through two complementary paths:
+
+- **Record path** (free): `get()`, metadata-level `find()`, and
+  filter-based `related()` resolve directly through the immutable record
+  layer. Ids untouched since the pin still ride the live fast paths.
+- **Index path** (paid once): index-accelerated queries — semantic/vector
+  search, graph traversal, cursors, aggregation — are served by an
+  **at-generation index materialization** built lazily on first use:
+  Brainy reconstructs in-memory indexes over the exact record set at that
+  generation. This costs O(n at the pinned generation) time and memory,
+  **once per `Db`**, cached until `release()`. That is the open-core price
+  of historical index queries, stated plainly.
+
+A native index provider implementing the optional
+`VersionedIndexProvider` plugin capability serves the same historical reads
+from its retained index segments **without any rebuild** — the materializer
+is the correctness baseline, the provider is the accelerator. Semantics are
+identical on both paths.
+
+### History granularity — the honest limit
+
+Generation *records* are written per `transact()` batch only.
+Single-operation writes (`add`/`update`/`remove`/`relate`/… outside
+`transact()`) advance the generation counter — so watermarks and CAS stay
+sound — but do **not** stage before-images: they remain visible through
+earlier pins and are not reported by `db.since()`. Code that needs pinned
+isolation across its own writes uses `transact()`. This is the documented
+8.0 contract, not an accident.
+
+## Speculative writes: `db.with()`
+
+`db.with(ops)` returns a new `Db` whose reads see the operations applied
+**in memory, on top of the view** — Datomic's `with`. Nothing touches disk,
+the generation counter, or index providers:
+
+```typescript
+const current = brain.now()
+const whatIf = await current.with([
+  { op: 'update', id: employeeId, metadata: { team: 'platform' } }
+])
+
+await whatIf.find({ where: { team: 'platform' } })   // sees the change
+await brain.get(employeeId)                          // unchanged — nothing committed
+```
+
+**The one boundary:** overlay entities carry no embeddings (`with()` never
+invokes the embedder), so index-accelerated queries and `persist()` on a
+speculative view throw `SpeculativeOverlayError` rather than returning
+silently incomplete results. `get()`, metadata-filter `find()`, and
+filter-based `related()` work fully on overlays. To get the full surface,
+commit the same operations with `brain.transact()`.
+
+## Retention and compaction
+
+Historical records cost disk space, so retention is explicit:
+
+- Every live `Db` holds a refcounted **pin**; a record-set is never
+  reclaimed while any pin could need it — pinned reads stay correct across
+  compaction, always.
+- The **`retention`** knob governs auto-compaction (on every `flush()`/
+  `close()`): unset → ADAPTIVE (disk/RAM-pressure, zero-config) · `'all'` →
+  unbounded · `{ maxGenerations?, maxAge?, maxBytes? }` → explicit caps.
+  `brain.compactHistory({ maxGenerations?, maxAge?, maxBytes? })` reclaims
+  manually on the same caps, and records the **horizon** — `asOf()` below it
+  throws `GenerationCompactedError`, explicitly, never partial data.
+- To keep a state readable forever, `persist()` it first: snapshots are
+  self-contained and unaffected by compaction of the source store.
+
+Release `Db` values you do not keep (including the ones `transact()`
+returns). A `FinalizationRegistry` backstop releases leaked pins at garbage
+collection, but explicit `release()` is what makes compaction
+deterministic.
+
+## Durability: snapshots and restore
+
+`db.persist(path)` cuts a **self-contained snapshot** under the store's
+commit mutex, so no commit or compaction can interleave. On filesystem
+storage it is built from **hard links**: because every data file is
+immutable-by-rename, linking is safe — the snapshot is created without
+copying entity data, shares disk space with the source, and later writes to
+the source can never alter it (rewrites swap inodes; the snapshot keeps the
+old bytes). Cross-device targets fall back to byte copies; in-memory stores
+serialize to the same directory layout, producing a real, durable store.
+
+Two rules keep snapshots honest:
+
+- `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 `GenerationConflictError` instead of persisting the
+  wrong state.
+- `brain.restore(path, { confirm: true })` replaces the store's entire
+  state from a snapshot via byte copy (never links — the snapshot stays
+  independent), rebuilds all indexes, and floors the generation counter so
+  observed generation numbers are never reissued. Live pins do not survive
+  a restore — release them first (a warning is logged when any exist).
+
+`Brainy.load(path)` (or `brain.asOf(path)`) opens a snapshot as a
+self-contained **read-only** store with the full query surface, including
+vector search.
+
+## Reserved fields
+
+Some field names belong to Brainy, not to your metadata. They live at **top
+level** on every entity and relationship, have dedicated write paths, and may
+never appear inside a `metadata` bag:
+
+| Entities (nouns) | Relationships (verbs) | Canonical write path |
+|---|---|---|
+| `noun` | `verb` | the `type` param of `add()` / `relate()` |
+| `subtype` | `subtype` | the `subtype` param |
+| `visibility` | `visibility` | the `visibility` param (`'public'` \| `'internal'`) |
+| `confidence` | `confidence` | the `confidence` param |
+| `weight` | `weight` | the `weight` param |
+| `service` | `service` | the `service` param (fixed at create time) |
+| `data` | `data` | the `data` param |
+| `createdBy` | `createdBy` | the `createdBy` param of `add()` (system-managed on verbs) |
+| `createdAt`, `updatedAt`, `_rev` | `createdAt`, `updatedAt`, `_rev` | system-managed (`ifRev` for CAS) |
+
+The canonical machine-readable lists are exported as
+`RESERVED_ENTITY_FIELDS` and `RESERVED_RELATION_FIELDS` (defined in
+`src/types/reservedFields.ts`, the single source of truth). Three layers
+enforce the contract:
+
+1. **Compile time** — every `metadata` param (`add`, `update`, `relate`,
+   `updateRelation`, and the matching `transact()` operations) rejects a
+   literal reserved key as a TypeScript error.
+2. **Write time** — untyped (JavaScript) callers that pass one anyway are
+   normalized: user-settable fields (`confidence`, `weight`, `subtype`, and
+   `service`/`createdBy` at create time) are remapped to their dedicated
+   param — **top-level wins** when both are supplied — and system-managed
+   fields are dropped with a one-shot warning naming the correct write path.
+   `update({ metadata: { confidence: 0.9 } })` therefore behaves exactly
+   like `update({ confidence: 0.9 })`.
+3. **Read time** — every read path (`get`, `find`, `search`,
+   `related`, batch reads, and historical `asOf()` materialization)
+   surfaces reserved fields **only at top level**: `entity.metadata` and
+   `relation.metadata` contain only your custom fields, always.
+
+```typescript
+const id = await brain.add({
+  type: 'document', subtype: 'invoice',
+  data: 'Invoice #42', confidence: 0.95,        // reserved → top-level params
+  metadata: { customer: 'acme', total: 129.5 }  // custom fields only
+})
+
+const entity = await brain.get(id)
+entity.confidence                                // 0.95 — top level
+entity.metadata                                  // { customer: 'acme', total: 129.5 }
+```
+
+### Visibility — `public` / `internal` / `system`
+
+`visibility` is a reserved tier that controls whether an entity or relationship
+surfaces on Brainy's **default** user-facing reads. The absence of the field is
+exactly equivalent to `'public'`.
+
+| Tier | Counted in `getNounCount()` / `stats()`? | Returned by default `find()` / `related()`? | Opt-in |
+|---|---|---|---|
+| `'public'` (default, or field absent) | yes | yes | — |
+| `'internal'` | no | no | `find({ includeInternal: true })` / `related({ includeInternal: true })` |
+| `'system'` | no | no | `find({ includeSystem: true })` / `related({ includeSystem: true })` |
+
+- **`'public'`** — normal data. Counted and returned everywhere. Stored lean:
+  the field is omitted on disk for public records, so existing data needs no
+  migration.
+- **`'internal'`** — your app's own bookkeeping (audit trails, derived caches,
+  scratch entities) that should not pollute default queries, counts, or
+  `stats()`, yet must stay retrievable on demand. Set it via the `visibility`
+  param; read it back with the `includeInternal` opt-in.
+- **`'system'`** — Brainy's own plumbing (for example the Virtual File System
+  root entity). Hidden everywhere by default — even when `includeInternal` is
+  set — and surfaced only with the explicit `includeSystem` opt-in. The
+  `'system'` tier is **not** part of the public `add()` / `relate()` param type
+  (`'public' | 'internal'`); only internal Brainy code assigns it.
+
+The opt-ins are applied as a **hard candidate filter** — hidden entities are
+removed before `limit` / `offset` are applied, so a default `find({ limit: 10 })`
+always returns ten *visible* results when that many exist, never a short page.
+
+```typescript
+// App-internal scratch entity: present, retrievable, but out of the way.
+await brain.add({ type: 'task', data: 'reindex job', visibility: 'internal' })
+
+await brain.getNounCount()                       // unchanged — internal not counted
+await brain.find({ type: 'task' })               // [] — hidden by default
+await brain.find({ type: 'task', includeInternal: true })   // includes it
+
+// A brand-new brain reports zero user entities even though the VFS root exists:
+const fresh = new Brainy()
+await fresh.init()
+await fresh.getNounCount()                        // 0 — the root is visibility:'system'
+```
+
+> **Note (8.0):** the structural `Contains` edges the VFS creates between
+> directories and files are left at the default (`public`) visibility for now —
+> only the VFS *root entity* is `'system'`. Marking those edges system requires
+> companion changes to VFS traversal and is out of scope for this change.
+
+## What is not guaranteed
+
+Stated plainly, so nothing surprises you in production:
+
+- **Single-writer.** Brainy is a single-writer, many-reader database
+  ([multi-process model](./multi-process.md)). Transactions are atomic
+  within one writer process — there is no distributed or cross-process
+  transaction coordination.
+- **History granularity.** Every write is its own immutable generation —
+  `transact()` batches AND single-operation `add`/`update`/`remove`/`relate`.
+  A pin always freezes against later writes, and every write is addressable
+  via `asOf()`. (`transact()` groups several operations into ONE atomic
+  generation; durability of single-op history is batched via async
+  group-commit — a hard crash can lose only the last un-flushed window's
+  *history*, never live data.)
+- **Compacted history is gone.** `asOf()` below the compaction horizon
+  fails explicitly; persist what you must keep.
+- **Counter persistence is coalesced for single-operation writes.** Durable
+  artifacts (records, manifests, snapshots) always persist the counter at
+  their own commit points, so a crash inside the coalescing window can lose
+  only counter values nothing durable ever referenced.
+- **Speculative overlays are metadata-only readers.** Index-accelerated
+  queries on `with()` views throw rather than guess.
+
+## Where to go next
+
+- [Snapshots & Time Travel](../guides/snapshots-and-time-travel.md) — the
+  recipes: backup, restore, time-travel debugging, what-if analysis, audit
+  trails.
+- [Optimistic concurrency with `_rev`](../guides/optimistic-concurrency.md)
+  — the per-entity CAS pattern.
+- [ADR-001: Generational MVCC](../ADR-001-generational-mvcc.md) — the full
+  design record, including the persisted layout and the proof table.

docs/concepts/generation-fact-log.md

@@ -0,0 +1,117 @@
+---
+title: The Generation Fact Log
+slug: concepts/generation-fact-log
+public: true
+category: concepts
+template: concept
+order: 6
+description: Every committed write also appends a self-verifying "fact" — an after-image commit record — to an append-only log. What facts are, the crash-safety model, the scanFacts() streaming surface, family stamps, and how index providers consume the log for sequential heals.
+next:
+  - concepts/consistency-model
+  - guides/snapshots-and-time-travel
+---
+
+# The Generation Fact Log
+
+Since 8.4.0, every committed generation also appends a **fact** — a compact record of what each
+touched entity or relationship *became* — to an append-only, checksummed log under
+`_generations/facts/`. Where the generational history answers *"what did things look like
+before?"* (before-images, powering `asOf()` and rollback), the fact log answers *"what happened,
+in order?"* — one sequential, self-verifying stream of the store's present being written.
+
+Nothing about querying changes. The fact log exists for three consumers:
+
+1. **Index heals and rebuilds** — one sequential read in commit order replaces a per-entity
+   directory walk over millions of files.
+2. **Incremental catch-up** — a derived index that knows which generation it reflects reads *just
+   the gap*, instead of rebuilding from scratch.
+3. **Replay and audit tooling** — anything that wants the store's committed timeline as a stream.
+
+## What a fact is
+
+One fact per committed generation:
+
+- **`generation`** and **`timestamp`** — which commit, when.
+- **`ops`** — every write in that commit: `{ kind: 'noun' | 'verb', id, record }` where `record`
+  holds the entity's full after-image (both stored legs), or **`null` for a tombstone** — a
+  removal carries no body, by design.
+- **`meta`** — the transaction metadata `transact()` was submitted with, when present.
+- **`blobHashes`** — content-blob references, for exact reclamation accounting.
+
+Facts accumulate **from the first write after upgrading** — pre-existing history is not
+retroactively converted, and consumers fall back to the enumeration walk when no log exists.
+
+## Crash safety, in one paragraph
+
+Facts are appended and fsynced **inside the same durability window as the commit itself**, before
+the commit point — so after a crash, the log can only ever be *ahead* of committed truth, never
+behind it with a hole. On open, the store reconciles the log back to the committed watermark:
+torn tails are detected by per-record checksums and cut; whole records beyond the watermark are
+truncated. The invariant every reader can rely on: **an absent generation was never committed; a
+present fact was.** `transact()` facts are durable the moment `transact()` returns; single-op
+facts share the same group-commit flush as the rest of their generation, so a hard kill loses the
+fact and the generation *together* — never a torn state.
+
+## Reading the log
+
+```typescript
+const scan = brain.scanFacts({ fromGeneration: 1 })
+if (scan) {
+  // Telemetry up front — progress bars get a denominator from second zero.
+  console.log(scan.headGeneration, scan.segmentCount, scan.approxFactCount)
+
+  for await (const batch of scan.batches()) {
+    // Each batch: { facts, firstGeneration, lastGeneration, factCount, byteSize, segmentId }
+    for (const fact of batch.facts) {
+      for (const op of fact.ops) {
+        if (op.record === null) {
+          // a tombstone: op.id was removed in this generation
+        }
+      }
+    }
+  }
+
+  console.log(scan.summary()) // { factsYielded, segmentsRead } — the cross-check
+}
+```
+
+- `scanFacts()` returns `null` when the store hosts no fact log (older store, or a storage adapter
+  without binary append support) — fall back to enumerating entities.
+- Scans run against a **snapshot**: facts appended after the scan opens never bleed in, each fact
+  is yielded exactly once, and a detected gap aborts loudly — never a silent skip.
+- `brain.factSegmentPaths()` returns the immutable, *sealed* segment files for zero-copy consumers
+  (the append-mutable tail is excluded — read it through `scanFacts()`).
+
+## Family stamps: how a projection proves it's current
+
+Anything derived from the store — an index, the entity file tree itself — carries a **family
+stamp**: a small JSON record of *which committed generation the projection reflects*
+(`sourceGeneration`) plus the invariants that verify it whole (exact per-file byte sizes for
+bounded families; rollup invariants like entity counts for unbounded ones). At open, coherence is
+a **comparison**, not a walk:
+
+- stamp equals the committed watermark and invariants hold → serve;
+- stamp is behind → the projection reads just the gap from the fact log;
+- invariants fail → loud, named divergence — `brain.repairIndex()` rebuilds from canonical and
+  re-stamps.
+
+The verifier is exported (`verifyFamilyStamp`) so every projection — TypeScript or native — runs
+literally the same check.
+
+## For plugin authors: the storage capability
+
+Index providers receive the storage adapter, not the brain — so the host wires the log onto it.
+Feature-detect and prefer the stream; fall back to enumeration:
+
+```typescript
+const scan = storage.scanFacts?.({ fromGeneration: stamp.sourceGeneration + 1 })
+if (scan) {
+  // sequential catch-up from the log
+} else {
+  // enumeration walk (older store or adapter)
+}
+const committed = storage.committedGeneration?.() // the watermark stamps compare against
+```
+
+Providers must never construct their own reader over the log's files — the open path belongs to
+the single writer (it reconciles the log at open); the capability is the sanctioned seam.

docs/concepts/multi-process.md

@@ -0,0 +1,153 @@
+---
+title: Multi-Process Model
+slug: concepts/multi-process
+public: true
+category: concepts
+template: concept
+order: 5
+description: How Brainy coordinates a single writer with any number of readers on a filesystem data directory — and how to safely inspect a live store.
+next:
+  - guides/inspection
+---
+
+# Multi-Process Model
+
+Brainy is a **single-writer, many-reader** database when backed by filesystem
+storage. This page explains the model, the guarantees, and the safe ways to
+inspect a live store from a second process.
+
+## The rule
+
+For one data directory:
+
+- **One writer** at a time. The writer acquires an exclusive lock on the
+  directory at `init()` and releases it on `close()`.
+- **Any number of readers**, concurrent with each other and with the writer.
+  Readers open via `Brainy.openReadOnly()` — they never touch the writer
+  lock.
+
+Any attempt to open a second writer on the same directory throws:
+
+```
+BrainyError: Another writer holds this Brainy directory.
+  PID:        1774431 on host app-host-1
+  Started:    2026-05-15T14:22:11Z
+  Heartbeat:  2026-05-15T14:22:34Z
+  Version:    7.21.0
+  Directory:  /data/brain
+```
+
+This is intentional. Two writers sharing a directory would silently corrupt
+in-memory indexes and produce wrong query results — the worst possible default
+for an operations tool.
+
+## Why a lock?
+
+Brainy keeps its primary indexes (HNSW, metadata, graph adjacency) in memory.
+On disk, those indexes are persisted incrementally as writes flush. A second
+process opening the same directory:
+
+- Loads the *persisted* state into a fresh in-memory copy.
+- Has no awareness of writes the first process buffered but hasn't flushed.
+- Will overwrite the persisted state on its own next flush, racing the first
+  process and corrupting whichever wins.
+
+The fix is the lock: refuse to open a second writer. SQLite has done the same
+since the late 1990s (`SQLITE_BUSY`).
+
+## What about Cor?
+
+Brainy + Cor compose cleanly under this model:
+
+- Cor stores its column-index segments inside the same `rootDir` (under
+  `indexes/_column_index/{field}/`).
+- Segments (`*.cidx` files) are **immutable** once written. Cor mmaps them
+  read-only.
+- The `MANIFEST.json` per field is updated via atomic rename — readers see
+  either the old or new manifest, never a torn file.
+
+A reader process can safely mmap Cor segments alongside a live writer
+without coordination. The single Brainy writer lock at
+`<rootDir>/locks/_writer.lock` covers Cor too, because Cor segment
+writes happen on the writer's side.
+
+## Stale-lock detection
+
+If a writer crashes or is forcibly killed, its lock file is left behind. To
+avoid a permanently-jammed directory, Brainy treats a lock as stale when:
+
+1. The recorded `hostname` equals the current host (cross-host PID checks
+   are unsafe), AND
+2. The recorded `pid` is no longer alive (`process.kill(pid, 0)` returns
+   `ESRCH`), OR the `lastHeartbeat` field is older than 60 seconds.
+
+A live writer rewrites `lastHeartbeat` every 10 seconds, so a hung writer
+that's missed several heartbeats is treated as dead. Stale locks are
+overwritten with a warning.
+
+If stale detection cannot prove the existing lock is dead — for example, a
+crashed writer on a different host writing to a shared filesystem — pass
+`{ force: true }` to override. A warning is logged either way.
+
+## Heartbeat and shutdown
+
+The heartbeat interval rewrites the lock file every 10 seconds. The timer
+is unref'd, so it does not keep the event loop alive on its own.
+
+On normal shutdown the writer releases the lock in `close()`. The shutdown
+hooks Brainy registers for `SIGTERM`, `SIGINT`, and `beforeExit` also
+release the lock so a container restart doesn't strand the directory.
+
+## How to inspect a live writer
+
+Use `Brainy.openReadOnly()`. It does not acquire the writer lock, so it
+coexists with whatever the writer is doing:
+
+```typescript
+const reader = await Brainy.openReadOnly({
+  storage: { type: 'filesystem', path: '/data/brain' }
+})
+
+const stats = await reader.stats()
+const bookings = await reader.find({ where: { entityType: 'booking' } })
+
+await reader.close()
+```
+
+What the reader sees reflects the writer's most recent **flush** to disk. If
+you need fresher state, ask the writer to flush before opening:
+
+```typescript
+const reader = await Brainy.openReadOnly({
+  storage: { type: 'filesystem', path: '/data/brain' }
+})
+
+const acked = await reader.requestFlush({ timeoutMs: 5000 })
+if (!acked) {
+  console.warn('Writer did not respond; results reflect last natural flush.')
+}
+
+const fresh = await reader.find({ where: { entityType: 'booking' } })
+```
+
+The CLI `brainy inspect` subcommands all do this for you by default
+(`--no-fresh` to opt out).
+
+## What's not enforced (yet)
+
+- **Non-filesystem backends** are out of scope in 8.0, which ships only the
+  filesystem and memory adapters. A custom `BaseStorage` subclass that is not
+  filesystem-backed does not enforce multi-process locking by default: two
+  processes can both succeed at `init()` in writer mode and clobber each
+  other's writes. A best-effort warning is logged in writer mode against a
+  non-filesystem backend.
+- **Long-running readers** do not automatically pick up new Cor segments
+  the writer publishes. One-shot inspector calls re-open the store and see
+  fresh segments; a reader that stays open for hours sees its column store
+  as-of the time it opened.
+
+## Reading material
+
+- `Brainy.openReadOnly()` — [API reference](../api/brainy.md)
+- `brainy inspect` — [inspection guide](../guides/inspection.md)
+- Cor columnar storage — see `node_modules/@soulcraft/cor/README.md`

docs/concepts/storage-adapters.md

@@ -0,0 +1,189 @@
+---
+title: Storage Adapter Inheritance Contract
+slug: concepts/storage-adapters
+public: true
+category: concepts
+template: concept
+order: 6
+description: How storage adapters extend Brainy's BaseStorage and FileSystemStorage to inherit multi-process safety, what plugin authors need to override, and the contract Brainy promises to keep stable.
+next:
+  - concepts/multi-process
+  - guides/inspection
+---
+
+# Storage Adapter Inheritance Contract
+
+Brainy's storage layer is designed for plugins to extend cleanly. A plugin
+that subclasses `BaseStorage` or `FileSystemStorage` inherits new behavior
+Brainy adds over time without code changes — provided the import resolution
+brings in the right Brainy version at runtime.
+
+This page documents what plugin authors can rely on, what they need to
+override, and the install-time failure modes that the defensive
+`hasStorageMethod()` guard exists to handle.
+
+## The class hierarchy
+
+```
+BaseStorageAdapter         (counts, batch ops, multi-tenancy hooks)
+        ↑
+BaseStorage                (type-statistics, lifecycle helpers, generation
+                            hooks, default no-op multi-process methods)
+        ↑
+FileSystemStorage          (real filesystem I/O, writer-lock implementation,
+                            flush-request watcher, atomic writes)
+        ↑
+<your plugin's storage>    (Cor's MmapFileSystemStorage, etc.)
+```
+
+When you `extend FileSystemStorage`, your adapter inherits every method on
+the chain — including the ones Brainy adds in a later release — for free.
+JavaScript's prototype chain resolves method lookups dynamically; nothing
+about the inheritance is baked in at class-definition time.
+
+## What you inherit for free
+
+A plugin whose storage class extends `FileSystemStorage` automatically gets
+the full multi-process safety surface:
+
+| Method | What it does | Override? |
+|---|---|---|
+| `acquireWriterLock(opts)` | Write `_writer.lock`, start heartbeat, throw on conflict | No |
+| `releaseWriterLock()` | Clean up lock file + heartbeat timer | No |
+| `readWriterLock()` | Read lock file as `WriterLockInfo` | No |
+| `startFlushRequestWatcher(cb)` | Poll `_flush_requests/` and invoke `cb` | No |
+| `stopFlushRequestWatcher()` | Stop the polling timer | No |
+| `requestFlushOverFilesystem(timeoutMs)` | Drop a `.req`, await `.ack` | No |
+| `supportsMultiProcessLocking()` | Return `false` (default) | **Yes — override to `true`** |
+
+The only required override is the capability flag. Returning `true` from
+`supportsMultiProcessLocking()` is the signal Brainy uses to decide whether
+to call `acquireWriterLock()` at init.
+
+```typescript
+import { FileSystemStorage } from '@soulcraft/brainy'
+
+export class MmapFileSystemStorage extends FileSystemStorage {
+  public supportsMultiProcessLocking(): boolean {
+    return true
+  }
+  // ... your mmap-specific overrides ...
+}
+```
+
+That's the full ceremony for inheriting multi-process safety.
+
+## When NOT to extend FileSystemStorage
+
+If your storage is **not filesystem-backed** (a custom
+network backend), extend `BaseStorage` directly:
+
+```typescript
+import { BaseStorage } from '@soulcraft/brainy'
+
+export class MyCloudStorage extends BaseStorage {
+  // BaseStorage's default no-op implementations of the multi-process
+  // methods stay in effect. `supportsMultiProcessLocking()` returns false
+  // by default — keep it that way unless you've implemented an object-
+  // versioned lease or similar cross-process synchronization for your
+  // backend.
+}
+```
+
+Brainy treats cloud backends as not-multi-process-safe by default and logs a
+one-line warning at init. That's the correct behavior until cloud locking
+ships (currently out of scope — see
+[`concepts/multi-process`](./multi-process.md)).
+
+## What `hasStorageMethod()` actually guards against
+
+The defensive check at every new-storage-method call site (`brainy.ts`,
+`hasStorageMethod(name)`) does **not** exist to handle "plugin bundles a
+stale BaseStorage." Plugins ship a dist that preserves the dynamic ESM
+import (verify in your plugin's `dist/`: `import { FileSystemStorage } from
+'@soulcraft/brainy'` is not rewritten to a vendored copy). The prototype
+chain at runtime resolves to whatever Brainy version your consumer has
+installed.
+
+`hasStorageMethod()` protects against **build/install artifacts** that break
+the prototype chain at the consumer-app level:
+
+- **Stale `node_modules`** — a lingering install from before the consumer
+  upgraded Brainy. The package.json says `@soulcraft/brainy@7.22.0` but
+  `node_modules/@soulcraft/brainy` is still 7.20.x.
+- **Lockfile drift** — `bun.lockb` / `package-lock.json` pins a brainy
+  version older than the package.json range, and `bun install` honors the
+  lockfile.
+- **Docker layer cache** — the image reuses a `node_modules` from an
+  earlier build that predates the brainy bump.
+- **Bundler quirks** — some bundlers (esbuild, webpack) flatten the
+  prototype chain at build time and lose later prototype mutations. Brainy
+  doesn't mutate prototypes at runtime, but bundler behavior can still
+  cause method lookups to fail in non-Node environments.
+
+In any of those, calling `storage.acquireWriterLock(...)` unconditionally
+throws `TypeError: storage.acquireWriterLock is not a function`. The guard
+turns that into a logged warning + graceful no-op so the app still boots,
+and the warning names the adapter class plus a remediation hint:
+
+```
+[brainy] Storage adapter `MmapFileSystemStorage` is missing the multi-process
+methods on its prototype chain. Writer locking and the flush-request RPC are
+disabled for this directory. Likely fix: clean install (`rm -rf node_modules
+bun.lockb && bun install`) or rebuild your container image to refresh
+`@soulcraft/brainy` to ≥7.21. See docs/concepts/storage-adapters.md.
+```
+
+## Authoring a new storage adapter — minimum checklist
+
+1. **Extend the right base class.**
+   - Filesystem-backed → `FileSystemStorage`.
+   - Cloud / network / custom → `BaseStorage`.
+
+2. **Override the capability flag.** If filesystem-backed:
+   ```typescript
+   public supportsMultiProcessLocking(): boolean { return true }
+   ```
+
+3. **Don't `super.X()`-wrap the multi-process methods**. They're inherited;
+   leaving them inherited means `hasStorageMethod()` finds them on the
+   prototype chain. Re-declaring them as `super.X()` wrappers makes the
+   helper resolve to your wrapper, which can fool the guard if your
+   constructor runs before the super class initializes.
+
+4. **Do override `init()` / `flush()` / `close()`** as needed. Always call
+   `super.init()` / `super.flush()` / `super.close()` first so the
+   filesystem prep, writer-lock acquisition, and lock release happen in the
+   expected order.
+
+5. **Verify the inheritance.** A one-line smoke test in your plugin's
+   `__tests__/`:
+   ```typescript
+   const s = new MyStorage(rootDir)
+   await s.init()
+   assert(typeof s.acquireWriterLock === 'function')
+   assert(s.supportsMultiProcessLocking() === true)
+   ```
+   If `acquireWriterLock` is undefined the prototype chain is broken at
+   install time — fix install, not your plugin.
+
+6. **Pin your peer dep generously.** `"peerDependencies": {
+   "@soulcraft/brainy": "^7.21.0" }` accepts any compatible 7.x. Don't pin
+   to an exact patch unless you're tracking a known regression.
+
+## Future direction
+
+The 7 multi-process methods are currently defaults on `BaseStorage`. A
+future refactor may extract them into a `MultiProcessSafeStorage`
+interface/mixin for cleaner separation — only adapters that opt in would
+expose them. This would require a minor bump and is tracked as an internal
+follow-up; consumers don't need to anticipate the change.
+
+## Reading material
+
+- [`concepts/multi-process`](./multi-process.md) — the writer-lock model,
+  heartbeat semantics, what the lock protects.
+- [`guides/inspection`](../guides/inspection.md) — `brainy inspect` and the
+  read-only mode.
+- `node_modules/@soulcraft/brainy/dist/storage/baseStorage.d.ts` — the
+  authoritative type signatures for every method this page references.

docs/development/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.

docs/development/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

docs/development/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.

docs/development/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.

docs/development/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.

docs/eli5.md

@@ -0,0 +1,155 @@
+---
+title: What is Brainy?
+slug: getting-started/what-is-brainy
+public: true
+category: getting-started
+template: guide
+order: 0
+description: Plain-language guide covering what Brainy does, how it compares to other tools, and what you can build with it. No jargon, no code — just clear analogies.
+next:
+  - getting-started/installation
+  - getting-started/quick-start
+---
+
+# Brainy and Cor — Explained Simply
+
+*A plain-language guide for anyone who wants to understand what this thing actually does.*
+
+---
+
+## What is Brainy?
+
+Imagine you have the world's smartest librarian.
+
+You walk up and say *"I'm looking for something about climate change — but only books published after 2020, and only ones written by authors I've already read."* A normal library would make you dig through a card catalogue, then cross-reference a list of authors, then scan the shelves yourself. That takes a while.
+
+Your smart librarian does all three at the same time — in less than the time it takes to blink.
+
+That's Brainy. It's a knowledge database that can search by **meaning**, follow **connections**, and filter by **labels** — all at once, in a single question.
+
+---
+
+## The Three Superpowers
+
+### 1. Meaning Search (the "fuzzy" superpower)
+
+When you search for "automobile," Brainy also finds results about "car," "vehicle," and "sedan" — because it understands what words *mean*, not just how they're spelled. It reads your data the way a person would, not the way a search box does.
+
+Think of it like the librarian who finds books on "heartbreak" when you ask for something about "loneliness."
+
+### 2. Relationship Walking (the "follow the thread" superpower)
+
+Every piece of information can be connected to other pieces. A Person *works at* a Company. A Project *depends on* a Tool. A Recipe *contains* Ingredients.
+
+Brainy can follow these connections across many hops in one step. Ask for "everything connected to this author, two steps out" and Brainy returns the author's books, the books' publishers, the publishers' other authors — without you needing to chain four separate lookups yourself.
+
+Think of it like the librarian who not only hands you the book you asked for, but also knows which shelf it came from, who donated it, and what other books arrived in the same donation.
+
+### 3. Label Filtering (the "narrow it down" superpower)
+
+Sometimes meaning and connections aren't enough — you need precision. "Only recipes with fewer than 500 calories." "Only events from last week." "Only documents tagged as urgent."
+
+Brainy can narrow any result set down by exact labels or ranges in the same breath as the other two searches. No extra steps.
+
+---
+
+## What Else Can It Do?
+
+- **Virtual file cabinet.** Brainy includes a full filesystem you can use to store, organize, and semantically search files — PDFs, documents, anything — the same way you search everything else.
+
+- **Live dashboards.** You can define running totals that Brainy keeps updated automatically — things like "total sales this month by region" or "average response time per service." Every time new data comes in, the numbers stay current with no manual recalculation.
+
+- **Time travel.** Every committed change becomes part of the database's history. You can pin the current state as a frozen view, see the whole knowledge base exactly as it was last week, try out changes in a scratch copy that never touches the real data, and take instant backups.
+
+- **Universal vocabulary.** Brainy ships with a shared language of 42 kinds of things (Person, Document, Task, Concept, Event…) and 127 kinds of connections (Contains, DependsOn, Creates, RelatedTo…). This means data from different sources speaks the same language without you having to translate.
+
+---
+
+## What is Cor?
+
+Cor is a turbocharger for Brainy.
+
+Same car. Same controls. Same fuel. You just swap in a faster engine under the hood, and everything that used to take a moment now happens instantly.
+
+Technically, Cor is an optional plugin written in Rust — a lower-level language that runs much closer to the raw metal of your processor. It plugs into Brainy and takes over the most compute-intensive work: the distance calculations that power meaning search, the number-crunching behind live aggregates, and the set operations that drive label filtering.
+
+You install it with one line, register it with one call, and Brainy automatically uses it everywhere it can help.
+
+---
+
+## How Much Faster?
+
+Plain language:
+
+- **Searches** go from "the blink of an eye" to "faster than a blink." The overall speedup is **5.2× on average** across all operations.
+- **Live aggregates** are rebuilt using all CPU cores in parallel, so re-indexing large datasets takes a fraction of the time.
+- **Analytics** that aren't even possible in pure JavaScript — real-time anomaly detection, streaming percentile estimates, approximate unique counts — become available because Cor brings the native capabilities required to run them efficiently.
+
+If Brainy is what makes knowledge fast, Cor is what makes Brainy feel instant.
+
+---
+
+## What Does Brainy Replace?
+
+Most applications that need to store and search knowledge end up stitching together several specialized tools. Brainy replaces all of them with one — a single free, open-source library in place of multiple paid services.
+
+### Before and After
+
+**Before Brainy** — a pile of services:
+- Pinecone (vectors) + Neo4j (graph) + MongoDB (docs)
+- Algolia (search) + Redis (cache) + PostgreSQL + pgvector
+- Plus glue code, sync jobs, ETL pipelines, and 3am incidents
+
+**After Brainy** — one thing:
+Search, graph, filter, files, time travel, and imports — unified in a single library.
+
+### What Each Tool Is Missing
+
+| Tool | Search | Graph | Filter | VFS | Time travel | Import |
+|---|:---:|:---:|:---:|:---:|:---:|:---:|
+| **Brainy** | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| *— Vector databases —* | | | | | | |
+| Pinecone | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ |
+| Weaviate | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ |
+| Qdrant | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ |
+| Chroma | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ |
+| *— Graph databases —* | | | | | | |
+| Neo4j | ❌ | ✅ | ✅ | ❌ | ❌ | ❌ |
+| *— Document stores —* | | | | | | |
+| MongoDB | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
+| Firestore | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
+| DynamoDB | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
+| *— Relational + vector —* | | | | | | |
+| PostgreSQL + pgvector | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ |
+| MySQL | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
+| SQLite | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
+| *— Search engines —* | | | | | | |
+| Elasticsearch | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ |
+| Algolia | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ |
+| *— Cache —* | | | | | | |
+| Redis | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
+
+Brainy is the only row with every box checked. And it runs all of them in a single query — no stitching services together.
+
+### One library, any scale
+
+Brainy scales from a quick experiment to serious production datasets without changing a line of code. Small datasets live entirely in memory. Larger ones spill to disk, where Brainy shards and compresses everything automatically. Need a backup or a copy? Snapshots are instant — the same API the whole way.
+
+Add Cor and you also unlock memory-mapped storage — aggregate state lives directly in the operating system's memory with zero serialization overhead, as fast as the hardware allows.
+
+---
+
+## What Can You Build?
+
+### Common applications
+
+- **AI agents with persistent memory** — Give any AI an always-on, self-organizing knowledge graph that persists between sessions and across agents.
+- **Searchable knowledge bases** — Build institutional memory that links documents automatically and surfaces answers across the full web of related information.
+- **Semantic document search** — Index PDFs, code, or media and find them by meaning, not just keywords.
+- **Relationship-aware recommendations** — Power product catalogs or content platforms where every recommendation understands what connects to what.
+- **Safe experiments** — Test risky changes against a scratch copy of the knowledge base, audit exactly what changed and when, and roll back to any snapshot instantly.
+- **Unified business platforms** — Combine booking, CRM, inventory, and analytics in one queryable knowledge graph with no sync pipeline.
+
+### What Brainy is good at
+
+Brainy is the engine underneath production systems that need to combine semantic search, structured filtering, and graph traversal in a single query — agent memory, knowledge-base platforms, business operations consoles, multi-agent coordination, and more. The combination of vector + graph + metadata search in one indexed call is what differentiates it from running three engines side by side.

docs/guides/MIGRATING_TO_V5.11.md

@@ -0,0 +1,230 @@
+# Migrating to v5.11.1
+
+## Overview
+
+v5.11.1 introduces a **breaking change** with **massive performance benefits**:
+
+- `brain.get()` now loads **metadata-only by default** (76-81% faster!)
+- Vector embeddings require **explicit opt-in**: `{ includeVectors: true }`
+
+**Impact**: Only ~6% of codebases need changes (code that computes similarity on retrieved entities).
+
+## What Changed
+
+### Before (v5.11.0 and earlier)
+
+```typescript
+const entity = await brain.get(id)
+// entity.vector was ALWAYS loaded (384 dimensions, 6KB)
+console.log(entity.vector.length)  // 384
+```
+
+### After (v5.11.1)
+
+```typescript
+// DEFAULT: Metadata-only (76-81% faster)
+const entity = await brain.get(id)
+console.log(entity.vector)  // [] (empty array - not loaded)
+
+// EXPLICIT: Full entity with vectors
+const entity = await brain.get(id, { includeVectors: true })
+console.log(entity.vector.length)  // 384
+```
+
+## Who Needs to Update?
+
+### ✅ NO CHANGES NEEDED (94% of code)
+
+If you use `brain.get()` for:
+- **VFS operations** (readFile, stat, readdir)
+- **Existence checks**: `if (await brain.get(id))`
+- **Metadata access**: `entity.data`, `entity.type`, `entity.metadata`
+- **Relationship traversal**
+- **Admin tools**, import utilities, data APIs
+
+→ **Zero changes needed, automatic 76-81% speedup!**
+
+### ⚠️ REQUIRES UPDATE (~6% of code)
+
+If you use `brain.get()` AND then compute similarity on the returned entity:
+
+```typescript
+// ❌ BEFORE (v5.11.0) - will break in v5.11.1
+const entity = await brain.get(id)
+const similar = await brain.similar({ to: entity.vector })  // entity.vector is [] !
+
+// ✅ AFTER (v5.11.1) - add includeVectors
+const entity = await brain.get(id, { includeVectors: true })
+const similar = await brain.similar({ to: entity.vector })  // Works!
+```
+
+**Note**: `brain.similar({ to: entityId })` (using ID) still works - no changes needed!
+
+## Migration Steps
+
+### Step 1: Find Affected Code
+
+Search your codebase for patterns that use vectors from `brain.get()`:
+
+```bash
+# Find brain.get() calls that access .vector
+grep -r "await brain.get(" --include="*.ts" --include="*.js" | \
+  grep -E "(\.vector|entity\.vector)"
+```
+
+### Step 2: Update Pattern-by-Pattern
+
+#### Pattern 1: Similarity Using Retrieved Entity Vector
+
+```typescript
+// ❌ BEFORE
+const entity = await brain.get(id)
+const similar = await brain.similar({ to: entity.vector })
+
+// ✅ AFTER - Option A: Add includeVectors
+const entity = await brain.get(id, { includeVectors: true })
+const similar = await brain.similar({ to: entity.vector })
+
+// ✅ AFTER - Option B: Use ID directly (recommended)
+const similar = await brain.similar({ to: id })
+```
+
+#### Pattern 2: Manual Vector Operations
+
+```typescript
+// ❌ BEFORE
+const entity = await brain.get(id)
+const magnitude = Math.sqrt(entity.vector.reduce((sum, v) => sum + v*v, 0))
+
+// ✅ AFTER
+const entity = await brain.get(id, { includeVectors: true })
+const magnitude = Math.sqrt(entity.vector.reduce((sum, v) => sum + v*v, 0))
+```
+
+#### Pattern 3: Vector Assertions in Tests
+
+```typescript
+// ❌ BEFORE
+const entity = await brain.get(id)
+expect(entity.vector).toBeDefined()
+expect(entity.vector.length).toBe(384)
+
+// ✅ AFTER
+const entity = await brain.get(id, { includeVectors: true })
+expect(entity.vector).toBeDefined()
+expect(entity.vector.length).toBe(384)
+```
+
+### Step 3: Verify Migration
+
+Run your test suite to catch any remaining issues:
+
+```bash
+npm test
+```
+
+Look for errors like:
+- `entity.vector is empty` or `entity.vector.length is 0`
+- `Cannot compute similarity on empty vector`
+
+Add `{ includeVectors: true }` wherever these errors occur.
+
+## Performance Impact
+
+### Before Migration
+```
+brain.get(): 43ms, 6KB per call
+VFS readFile(): 53ms per file
+VFS readdir(100 files): 5.3s
+```
+
+### After Migration
+```
+brain.get(): 10ms, 300 bytes per call (76-81% faster) ✨
+brain.get({ includeVectors: true }): 43ms, 6KB (unchanged)
+VFS readFile(): ~13ms per file (75% faster) ✨
+VFS readdir(100 files): ~1.3s (75% faster) ✨
+```
+
+**Result**:
+- VFS operations: **75% faster**
+- Metadata access: **76-81% faster**
+- Vector similarity: **Unchanged** (still fast when needed)
+
+## TypeScript Support
+
+The new `GetOptions` interface is fully typed:
+
+```typescript
+interface GetOptions {
+  /**
+   * Include 384-dimensional vector embeddings in the response
+   *
+   * Default: false (metadata-only for 76-81% speedup)
+   */
+  includeVectors?: boolean
+}
+
+// TypeScript will autocomplete and validate
+const entity = await brain.get(id, { includeVectors: true })
+```
+
+## Rollback Plan
+
+If you encounter issues, you can temporarily force full entity loading everywhere:
+
+```typescript
+// Temporary wrapper (NOT RECOMMENDED - defeats optimization)
+async function getLegacy(id: string) {
+  return brain.get(id, { includeVectors: true })
+}
+
+// Use throughout codebase while migrating
+const entity = await getLegacy(id)
+```
+
+**Important**: This defeats the 76-81% performance improvement. Only use temporarily while fixing affected code.
+
+## FAQ
+
+### Q: Why did you make this a breaking change?
+
+**A**: The performance gains are massive (76-81% speedup, 95% less bandwidth) and affect 94% of code positively. Only ~6% of code needs updates. The net benefit is enormous.
+
+### Q: Do I need to update my VFS code?
+
+**A**: No! VFS automatically benefits from the optimization with zero code changes. Your VFS operations are now 75% faster automatically.
+
+### Q: Will brain.similar() still work?
+
+**A**: Yes! `brain.similar({ to: entityId })` works exactly as before. Only `brain.similar({ to: entity.vector })` requires the entity to be loaded with `{ includeVectors: true }`.
+
+### Q: What about backward compatibility?
+
+**A**: Entities returned without vectors have `vector: []` (empty array), which is type-safe. Code that doesn't use vectors continues to work. Only code that explicitly uses `entity.vector` needs updating.
+
+### Q: Can I check if vectors are loaded?
+
+**A**: Yes! Check `entity.vector.length > 0` to detect if vectors were loaded.
+
+```typescript
+const entity = await brain.get(id)
+if (entity.vector.length > 0) {
+  // Vectors are loaded
+} else {
+  // Metadata-only
+}
+```
+
+## Support
+
+If you encounter migration issues:
+
+1. Check the [VFS Performance Guide](../vfs/VFS_PERFORMANCE.md)
+2. Review [API Reference](../api/README.md)
+3. See [Performance Documentation](../PERFORMANCE.md)
+4. File an issue: https://github.com/soulcraft/brainy/issues
+
+## Changelog
+
+See [CHANGELOG.md](../../CHANGELOG.md) for complete v5.11.1 release notes.

docs/guides/aggregation.md

@@ -0,0 +1,593 @@
+# Aggregation Guide
+
+> Real-time analytics on your entity data with incremental running totals
+
+## Overview
+
+Brainy's aggregation engine computes running totals at write time, so reading aggregate results is always O(1) regardless of dataset size. Define an aggregate once, and every `add()`, `update()`, and `delete()` automatically updates the running metrics.
+
+No batch jobs. No scheduled recalculations. Aggregates stay current with every write.
+
+**Defining over existing data:** if you define an aggregate on a store that already holds
+matching entities, Brainy backfills it from those entities on the first query (a one-time scan,
+then purely incremental). So `defineAggregate()` behaves the same whether you define it before
+or after the data exists.
+
+**Reopening a persisted brain:** aggregate state persists across restarts. Re-defining the
+same aggregate at boot (the normal declarative pattern) adopts the persisted state directly —
+no rescan. A backfill scan runs only when the definition actually changed, when no persisted
+state exists, or when the state failed to load; and however many aggregates need backfilling,
+they share a single scan.
+
+## Quick Start
+
+```typescript
+import { Brainy, NounType } from '@soulcraft/brainy'
+
+const brain = new Brainy()
+await brain.init()
+
+// 1. Define an aggregate
+brain.defineAggregate({
+  name: 'sales_by_category',
+  source: { type: NounType.Event },
+  groupBy: ['category'],
+  metrics: {
+    revenue: { op: 'sum', field: 'amount' },
+    count:   { op: 'count' },
+    average: { op: 'avg', field: 'amount' }
+  }
+})
+
+// 2. Add entities — aggregates update automatically
+await brain.add({
+  data: 'Coffee purchase',
+  type: NounType.Event,
+  metadata: { category: 'food', amount: 5.50 }
+})
+
+await brain.add({
+  data: 'Laptop purchase',
+  type: NounType.Event,
+  metadata: { category: 'electronics', amount: 1200 }
+})
+
+await brain.add({
+  data: 'Lunch purchase',
+  type: NounType.Event,
+  metadata: { category: 'food', amount: 12.00 }
+})
+
+// 3. Query results
+const results = await brain.find({ aggregate: 'sales_by_category' })
+
+// Results:
+// [
+//   { groupKey: { category: 'food' }, metrics: { revenue: 17.50, count: 2, average: 8.75 } },
+//   { groupKey: { category: 'electronics' }, metrics: { revenue: 1200, count: 1, average: 1200 } }
+// ]
+```
+
+## Aggregation Operations
+
+Brainy supports 7 aggregation operations:
+
+### `sum` — Running Total
+
+Adds up all values of a numeric field.
+
+```typescript
+metrics: {
+  total_revenue: { op: 'sum', field: 'amount' }
+}
+```
+
+### `count` — Entity Count
+
+Counts the number of matching entities. No `field` required.
+
+```typescript
+metrics: {
+  order_count: { op: 'count' }
+}
+```
+
+### `avg` — Running Average
+
+Computes `sum / count` incrementally.
+
+```typescript
+metrics: {
+  average_price: { op: 'avg', field: 'price' }
+}
+```
+
+### `min` — Minimum Value
+
+Tracks the minimum value across all entities in each group.
+
+```typescript
+metrics: {
+  lowest_price: { op: 'min', field: 'price' }
+}
+```
+
+### `max` — Maximum Value
+
+Tracks the maximum value across all entities in each group.
+
+```typescript
+metrics: {
+  highest_price: { op: 'max', field: 'price' }
+}
+```
+
+### `stddev` — Sample Standard Deviation
+
+Computes the sample standard deviation using Welford's numerically stable online algorithm. Updates incrementally without storing individual values.
+
+```typescript
+metrics: {
+  price_spread: { op: 'stddev', field: 'price' }
+}
+```
+
+### `variance` — Sample Variance
+
+Computes the sample variance (square of standard deviation) using Welford's online algorithm.
+
+```typescript
+metrics: {
+  price_variance: { op: 'variance', field: 'price' }
+}
+```
+
+## GROUP BY Dimensions
+
+Every aggregate requires at least one `groupBy` dimension. Results are grouped by the unique combinations of dimension values.
+
+### Plain Fields
+
+Group by a metadata field value:
+
+```typescript
+groupBy: ['category']
+// Produces groups: { category: 'food' }, { category: 'electronics' }, ...
+```
+
+### Multiple Fields
+
+Group by multiple fields for composite keys:
+
+```typescript
+groupBy: ['category', 'region']
+// Produces groups: { category: 'food', region: 'US' }, { category: 'food', region: 'EU' }, ...
+```
+
+### Time Windows
+
+Group by a timestamp field bucketed into time periods:
+
+```typescript
+groupBy: [{ field: 'date', window: 'month' }]
+// Produces groups: { date: '2024-01' }, { date: '2024-02' }, ...
+```
+
+Available time window granularities:
+
+| Window | Format | Example |
+|--------|--------|---------|
+| `hour` | `YYYY-MM-DDThh` | `2024-01-15T14` |
+| `day` | `YYYY-MM-DD` | `2024-01-15` |
+| `week` | `YYYY-Wnn` | `2024-W03` |
+| `month` | `YYYY-MM` | `2024-01` |
+| `quarter` | `YYYY-Qn` | `2024-Q1` |
+| `year` | `YYYY` | `2024` |
+| `{ seconds: N }` | ISO 8601 | Custom interval |
+
+### Combined Dimensions
+
+Mix plain fields and time windows:
+
+```typescript
+brain.defineAggregate({
+  name: 'monthly_sales',
+  source: { type: NounType.Event },
+  groupBy: ['region', { field: 'date', window: 'month' }],
+  metrics: {
+    revenue: { op: 'sum', field: 'amount' },
+    count: { op: 'count' }
+  }
+})
+
+// Produces groups like:
+// { region: 'US', date: '2024-01' }
+// { region: 'US', date: '2024-02' }
+// { region: 'EU', date: '2024-01' }
+```
+
+### Array Fields (Unnest)
+
+Group by **each element** of an array-valued field — for tag frequencies, label counts, and
+faceted breakdowns. Mark the dimension `{ field, unnest: true }`:
+
+```typescript
+brain.defineAggregate({
+  name: 'tag_frequency',
+  source: { type: NounType.Document },
+  groupBy: [{ field: 'tags', unnest: true }],
+  metrics: { count: { op: 'count' } }
+})
+
+// A document tagged ['ml', 'ai'] contributes once to the 'ml' group and once to 'ai'.
+// Duplicate tags on one entity count once; an entity with no tags joins no group.
+const top = await brain.queryAggregate('tag_frequency', { orderBy: 'count', order: 'desc' })
+// [ { groupKey: { tags: 'ai' }, metrics: { count: 3 }, count: 3 }, ... ]
+```
+
+## Querying Aggregates
+
+Aggregate results are queried through the standard `find()` method.
+
+### Basic Query
+
+```typescript
+const results = await brain.find({ aggregate: 'sales_by_category' })
+```
+
+### Filter by Group Key
+
+Use `where` to filter on group key values:
+
+```typescript
+const foodOnly = await brain.find({
+  aggregate: 'sales_by_category',
+  where: { category: 'food' }
+})
+```
+
+### Filter by Metric Value (HAVING)
+
+Use `having` to filter groups by their **computed metric values** — the analytics equivalent of
+SQL `HAVING`. (`where` filters group *keys*; `having` filters *metrics*.)
+
+```typescript
+const bigCategories = await brain.find({
+  aggregate: 'sales_by_category',
+  having: { revenue: { greaterThan: 1000 } }
+})
+```
+
+`having` accepts the same operators as `where`, applied to each group's metric results plus
+`count`. It is evaluated per group — **O(groups), independent of entity count** — before sorting
+and pagination, so it stays cheap even over billions of entities.
+
+### Sort and Paginate
+
+Sort by any metric or group key field:
+
+```typescript
+const topCategories = await brain.find({
+  aggregate: {
+    name: 'sales_by_category',
+    orderBy: 'revenue',
+    order: 'desc',
+    limit: 10
+  }
+})
+```
+
+### Combined Parameters
+
+`where`, `orderBy`, `limit`, and `offset` from the outer `find()` call merge automatically with the aggregate query:
+
+```typescript
+const recentTopSpenders = await brain.find({
+  aggregate: 'monthly_sales',
+  where: { region: 'US' },
+  orderBy: 'revenue',
+  order: 'desc',
+  limit: 12,
+  offset: 0
+})
+```
+
+### Result Format
+
+`find({ aggregate })` returns `Result<T>` rows (for uniformity with the rest of `find()`),
+with the aggregate fields surfaced **both** at the top level and, for backward compatibility,
+flattened into `metadata`:
+
+```typescript
+{
+  id: string,
+  score: 1.0,
+  type: NounType.Measurement,
+  groupKey: { category: 'food' },             // top-level — the group key values
+  metrics:  { revenue: 17.50, count: 2, average: 8.75 }, // top-level — computed metrics
+  count: 2,                                   // top-level — entities in the group
+  metadata: {                                 // legacy mirror of the same data
+    __aggregate: 'sales_by_category',
+    category: 'food',
+    revenue: 17.50, count: 2, average: 8.75
+  },
+  entity: Entity
+}
+```
+
+### `queryAggregate()` — the report-friendly view
+
+For dashboards and reports, prefer `brain.queryAggregate(name, params)`. It returns the clean
+`AggregateResult[]` shape directly — no search-result wrapper:
+
+```typescript
+const rows = await brain.queryAggregate('sales_by_category', {
+  orderBy: 'revenue',
+  order: 'desc',
+  limit: 10
+})
+// [
+//   { groupKey: { category: 'electronics' }, metrics: { revenue: 1200, count: 1, average: 1200 }, count: 1 },
+//   { groupKey: { category: 'food' }, metrics: { revenue: 17.50, count: 2, average: 8.75 }, count: 2 }
+// ]
+```
+
+It accepts the same `where` / `having` / `orderBy` / `order` / `limit` / `offset` params as the
+`find({ aggregate })` form.
+
+## Source Filtering
+
+Control which entities feed into an aggregate with the `source` property.
+
+### Filter by Entity Type
+
+```typescript
+brain.defineAggregate({
+  name: 'event_stats',
+  source: { type: NounType.Event },
+  groupBy: ['category'],
+  metrics: { count: { op: 'count' } }
+})
+```
+
+### Filter by Multiple Types
+
+```typescript
+source: { type: [NounType.Event, NounType.Document] }
+```
+
+### Filter by Metadata
+
+Use the same `where` syntax as `find()`:
+
+```typescript
+source: {
+  type: NounType.Event,
+  where: { domain: 'financial', subtype: 'transaction' }
+}
+```
+
+### Filter by Service
+
+For multi-tenant deployments:
+
+```typescript
+source: { service: 'tenant-123' }
+```
+
+Entities that don't match the source filter are silently skipped during incremental updates.
+
+## Incremental Updates
+
+The aggregation engine hooks into every write operation:
+
+### On `add()`
+
+When a new entity matches an aggregate's source filter:
+1. The group key is computed from the entity's metadata
+2. Each metric in the matching group is incremented
+3. New groups are created automatically
+
+### On `update()`
+
+When an existing entity is updated:
+1. The old entity's contribution is reversed from its group
+2. The new entity's contribution is applied to its (potentially different) group
+3. Handles group key changes — an entity moving from category "food" to "drink" updates both groups
+
+### On `delete()`
+
+When an entity is deleted:
+1. The entity's contribution is reversed from its group
+2. If a group becomes empty (all metric counts reach zero), it's removed
+
+### Aggregate Entity Exclusion
+
+Materialized `NounType.Measurement` entities are automatically excluded from all source matching, preventing infinite feedback loops. Entities with `service: 'brainy:aggregation'` or `metadata.__aggregate` are always skipped.
+
+## Materialization
+
+Materialization writes aggregate results as `NounType.Measurement` entities, making them automatically available through OData, Google Sheets, SSE, and webhook integrations.
+
+```typescript
+brain.defineAggregate({
+  name: 'daily_metrics',
+  source: { type: NounType.Event },
+  groupBy: [{ field: 'date', window: 'day' }],
+  metrics: {
+    total: { op: 'sum', field: 'amount' },
+    count: { op: 'count' }
+  },
+  materialize: true
+})
+```
+
+### Debounce Configuration
+
+During high-throughput ingestion, materialization is debounced to avoid excessive writes:
+
+```typescript
+materialize: {
+  debounceMs: 2000,      // Wait 2 seconds after last update before writing
+  trackSources: true     // Track which entities contributed
+}
+```
+
+The default debounce interval is 1000ms.
+
+## Multiple Aggregates
+
+Define multiple aggregates that process the same entities:
+
+```typescript
+// Revenue by category
+brain.defineAggregate({
+  name: 'category_revenue',
+  source: { type: NounType.Event },
+  groupBy: ['category'],
+  metrics: { total: { op: 'sum', field: 'amount' } }
+})
+
+// Monthly trends
+brain.defineAggregate({
+  name: 'monthly_trends',
+  source: { type: NounType.Event },
+  groupBy: [{ field: 'date', window: 'month' }],
+  metrics: {
+    revenue: { op: 'sum', field: 'amount' },
+    count: { op: 'count' },
+    avg_order: { op: 'avg', field: 'amount' }
+  }
+})
+
+// Regional breakdown with statistical analysis
+brain.defineAggregate({
+  name: 'regional_analysis',
+  source: { type: NounType.Event },
+  groupBy: ['region'],
+  metrics: {
+    revenue: { op: 'sum', field: 'amount' },
+    spread: { op: 'stddev', field: 'amount' },
+    variance: { op: 'variance', field: 'amount' }
+  }
+})
+```
+
+Each `add()` call updates all matching aggregates automatically.
+
+## Removing Aggregates
+
+Remove an aggregate and clean up its state:
+
+```typescript
+brain.removeAggregate('category_revenue')
+```
+
+## Persistence
+
+Aggregate definitions and running state are automatically persisted:
+
+- **On `flush()`/`close()`**: All dirty aggregate state is written to storage
+- **On `init()`**: Definitions and state are restored from storage
+- **Change detection**: Definition changes are detected via FNV-1a hashing — only changed aggregates reset their state on restart
+
+## Native Acceleration
+
+When [Cor](https://www.npmjs.com/package/@soulcraft/cor) is installed as a plugin, the aggregation engine automatically uses Rust-accelerated computation:
+
+- Incremental updates run in Rust with BTreeMap-backed precise MIN/MAX
+- Welford's online stddev/variance computed natively
+- Rebuild uses Rayon parallel iterators across CPU cores (above 1,000 entities)
+- Time window bucketing uses integer arithmetic without `Date` object allocation
+
+```typescript
+const brain = new Brainy({
+  plugins: ['@soulcraft/cor']
+})
+await brain.init()
+
+// Aggregation automatically uses native engine
+brain.defineAggregate({ ... })
+```
+
+Verify native acceleration is active:
+
+```typescript
+const diag = brain.diagnostics()
+console.log(diag.providers.aggregation)
+// { source: 'plugin' }
+```
+
+## Common Patterns
+
+### Financial Analytics
+
+```typescript
+brain.defineAggregate({
+  name: 'monthly_spending',
+  source: {
+    type: NounType.Event,
+    where: { domain: 'financial', subtype: 'transaction' }
+  },
+  groupBy: [
+    'category',
+    { field: 'date', window: 'month' }
+  ],
+  metrics: {
+    total:   { op: 'sum', field: 'amount' },
+    count:   { op: 'count' },
+    average: { op: 'avg', field: 'amount' },
+    highest: { op: 'max', field: 'amount' },
+    lowest:  { op: 'min', field: 'amount' }
+  },
+  materialize: true
+})
+```
+
+### Time-Series Monitoring
+
+```typescript
+brain.defineAggregate({
+  name: 'hourly_metrics',
+  source: { type: NounType.Event, where: { domain: 'monitoring' } },
+  groupBy: [
+    'service',
+    { field: 'timestamp', window: 'hour' }
+  ],
+  metrics: {
+    request_count:  { op: 'count' },
+    avg_latency:    { op: 'avg', field: 'latency_ms' },
+    max_latency:    { op: 'max', field: 'latency_ms' },
+    error_count:    { op: 'sum', field: 'is_error' },
+    latency_spread: { op: 'stddev', field: 'latency_ms' }
+  }
+})
+```
+
+### Content Analytics
+
+```typescript
+brain.defineAggregate({
+  name: 'content_stats',
+  source: { type: NounType.Document },
+  groupBy: ['author', { field: 'publishedAt', window: 'month' }],
+  metrics: {
+    articles:   { op: 'count' },
+    total_words: { op: 'sum', field: 'wordCount' },
+    avg_words:   { op: 'avg', field: 'wordCount' }
+  }
+})
+```
+
+## Performance
+
+Aggregation complexity per write is O(A x G x M) where A = matching aggregates, G = groupBy dimensions, M = metrics. For typical configurations (2-5 aggregates, 1-3 dimensions, 3-5 metrics), this is effectively O(1).
+
+With Cor native acceleration:
+
+| Operation | Throughput | Latency |
+|-----------|-----------|---------|
+| Incremental update (1K entities) | 809 ops/s | 1.2 ms |
+| Rebuild (10K entities) | 475 ops/s | 2.1 ms |
+| Rebuild (100K entities, Rayon) | 66 ops/s | 15.2 ms |
+| Query (1K groups, sort + paginate) | 986 ops/s | 1.0 ms |

docs/guides/enterprise-for-everyone.md

@@ -0,0 +1,441 @@
+# Enterprise for Everyone
+
+> **Philosophy**: We believe enterprise features should be available to everyone. This document shows what's available now and what's coming soon.
+
+## Our Philosophy: No Premium Tiers, No Limitations
+
+Brainy believes that **enterprise-grade features should be available to everyone**—from indie developers to Fortune 500 companies. Every Brainy installation includes the complete feature set with no artificial limitations, no premium tiers, and no feature gates.
+
+> "Why should a student project have worse data durability than a billion-dollar company? They shouldn't." - Brainy Philosophy
+
+## What You Get
+
+### ✅ Available Now
+Core enterprise features that work today.
+
+### 🚧 Coming Soon
+Enterprise features on our roadmap.
+
+### 🔒 Enterprise Security 🚧 Coming Soon
+
+**Everyone gets bank-level security features:**
+
+```typescript
+const brain = new Brainy({
+  security: {
+    encryption: 'aes-256-gcm',        // Military-grade encryption
+    keyRotation: true,                // Automatic key rotation
+    auditLog: true,                   // Complete audit trail
+    zeroKnowledge: true,              // Client-side encryption available
+    compliance: ['SOC2', 'HIPAA', 'GDPR']  // Compliance-ready
+  }
+})
+```
+
+**Features included:**
+- **At-rest encryption**: All data encrypted with AES-256
+- **In-transit encryption**: TLS 1.3 for all communications
+- **Key management**: Automatic rotation and secure storage
+- **Access control**: Role-based permissions
+- **Audit logging**: Every operation tracked
+- **Data residency**: Control where your data lives
+- **Zero-knowledge option**: Even Brainy can't read your data
+
+### 💾 Enterprise Durability ✅ Available Now
+
+**Everyone gets mission-critical reliability:**
+
+```typescript
+
+const brain = new Brainy({
+  augmentations: [
+      enabled: true,                    // Write-ahead logging
+      redundancy: 3,                    // Triple redundancy
+      checkpointInterval: 1000,         // Frequent checkpoints
+      crashRecovery: true,              // Automatic recovery
+      pointInTimeRecovery: true         // Time travel capability
+    })
+  ]
+})
+
+// Your data is as safe as any Fortune 500 company's
+```
+
+**Features included:**
+- **Write-ahead logging**: Never lose a write
+- **ACID compliance**: Full transactional guarantees
+- **Automatic backups**: Continuous protection
+- **Point-in-time recovery**: Restore to any moment
+- **Crash recovery**: Automatic healing
+- **Zero data loss**: RPO = 0
+- **High availability**: 99.99% uptime capable
+
+### 🚀 Enterprise Performance ✅ Available Now
+
+**Everyone gets blazing-fast performance:**
+
+```typescript
+// These optimizations are automatic and free for everyone
+const performance = {
+  vectorSearch: 'HNSW',              // O(log n) similarity search
+  fieldLookup: 'O(1)',               // Constant-time metadata access
+  caching: 'Multi-level',            // L1/L2/L3 intelligent caching
+  indexing: 'Automatic',             // Self-optimizing indexes
+  batching: 'Dynamic',               // Adaptive batch processing
+  parallelism: 'Auto-scaled',       // Uses all available cores
+  gpu: 'Auto-detected'               // GPU acceleration when available
+}
+```
+
+**Performance features:**
+- **Sub-millisecond queries**: With proper indexing
+- **Million+ entities**: Handles massive scale
+- **Streaming ingestion**: 100k+ operations/second
+- **Auto-optimization**: Learns and improves
+- **Resource adaptation**: Uses available hardware optimally
+- **No artificial limits**: No throttling or quotas
+
+### 📊 Enterprise Observability 🚧 Coming Soon
+
+**Everyone gets complete visibility:**
+
+```typescript
+import { MonitoringAugmentation } from 'brainy'
+
+const brain = new Brainy({
+  augmentations: [
+    new MonitoringAugmentation({
+      metrics: 'all',                  // Complete metrics
+      tracing: true,                   // Distributed tracing
+      profiling: true,                 // Performance profiling
+      alerting: true,                  // Anomaly detection
+      dashboard: true                  // Real-time dashboard
+    })
+  ]
+})
+
+brain.on('metrics', (metrics) => {
+  // Same metrics Facebook uses, but free for you
+  console.log({
+    qps: metrics.queriesPerSecond,
+    p99: metrics.latencyP99,
+    errorRate: metrics.errorRate,
+    cacheHit: metrics.cacheHitRate
+  })
+})
+```
+
+**Observability features:**
+- **Real-time metrics**: Operations, latency, throughput
+- **Distributed tracing**: Track requests across systems
+- **Performance profiling**: Find bottlenecks
+- **Anomaly detection**: Automatic alerts
+- **Custom dashboards**: Visualize your data
+- **Export to any system**: Prometheus, Grafana, DataDog
+
+### 🔄 Enterprise Integration 🚧 Coming Soon
+
+**Everyone gets seamless connectivity:**
+
+```typescript
+// Import from any data source
+await brain.importFromSQL('postgres://production-db')
+await brain.importFromMongo('mongodb://analytics')
+await brain.importFromAPI('https://api.company.com/data')
+await brain.importFromStream('kafka://events')
+
+// Export to any format
+await brain.exportToParquet('./data.parquet')
+await brain.exportToJSON('./backup.json')
+await brain.exportToSQL('mysql://backup')
+
+// Sync with any system
+await brain.syncWith({
+  elasticsearch: 'https://search.company.com',
+  redis: 'redis://cache.company.com',
+  webhooks: 'https://api.company.com/hooks'
+})
+```
+
+**Integration features:**
+- **Universal import**: SQL, NoSQL, CSV, JSON, XML, APIs
+- **Universal export**: Any format you need
+- **Real-time sync**: Keep systems in sync
+- **Streaming connectors**: Kafka, Redis, WebSockets
+- **Webhook support**: React to changes
+- **API generation**: Auto-generate REST/GraphQL APIs
+
+### 🌍 Scale
+
+**Everyone gets the same scale model:**
+
+```typescript
+// Pure JS by default; install the optional native provider for billions of vectors
+const brain = new Brainy()
+
+// 1 → ~1M vectors: pure-JS HNSW, zero extra setup
+// 1M → 10B+ vectors: install @soulcraft/cor for the native DiskANN provider
+```
+
+**Scaling model:**
+- **Single process, no cluster**: Brainy runs in one process — no coordinator,
+  no peer discovery, no consensus to operate
+- **Optional native provider**: install `@soulcraft/cor` to back the index with
+  on-disk DiskANN that scales to 10B+ vectors on one machine
+- **Per-tenant pools**: isolate tenants by giving each its own Brainy instance and
+  storage directory
+- **Horizontal read scaling**: run many reader processes against one shared on-disk
+  store (single writer, many readers); replicate the artifact with your operator
+  tooling
+
+### 🛡️ Enterprise Compliance 🚧 Coming Soon
+
+**Everyone gets compliance tools:**
+
+```typescript
+const brain = new Brainy({
+  compliance: {
+    gdpr: {
+      rightToDelete: true,           // Automatic PII deletion
+      rightToExport: true,           // Data portability
+      consentTracking: true,         // Consent management
+      dataMinimization: true         // Automatic data pruning
+    },
+    hipaa: {
+      encryption: true,               // PHI encryption
+      accessLogging: true,            // Access audit trail
+      minimumNecessary: true         // Access restrictions
+    },
+    sox: {
+      auditTrail: true,              // Complete audit log
+      changeControl: true,           // Version control
+      segregationOfDuties: true      // Role separation
+    }
+  }
+})
+```
+
+**Compliance features:**
+- **GDPR ready**: Full data privacy toolkit
+- **HIPAA compliant**: Healthcare data protection
+- **SOX compliant**: Financial controls
+- **CCPA support**: California privacy rights
+- **ISO 27001**: Information security
+- **PCI DSS**: Payment card security
+
+### 🤖 Enterprise AI/ML ⚠️ Partially Available
+
+> **Current**: Basic embeddings and vector search work. Advanced features coming soon.
+
+**Everyone gets advanced AI features:**
+
+```typescript
+// Advanced AI capabilities for everyone
+const brain = new Brainy({
+  ai: {
+    embeddings: 'state-of-the-art',  // Best models available
+    dimensions: 1536,                 // High-precision vectors
+    multimodal: true,                 // Text, image, audio
+    fineTuning: true,                 // Custom model training
+    activeLearning: true,             // Improves with usage
+    explainability: true              // Understand decisions
+  }
+})
+
+// Use enterprise AI features
+const results = await brain.find("complex natural language query")
+const explanation = await brain.explain(results)
+const recommendations = await brain.recommend(userId)
+const anomalies = await brain.detectAnomalies()
+```
+
+**AI features:**
+- **State-of-the-art models**: Latest embeddings
+- **Multi-modal support**: Text, images, code, audio
+- **Fine-tuning**: Adapt to your domain
+- **Active learning**: Improves with feedback
+- **Explainable AI**: Understand decisions
+- **Anomaly detection**: Find outliers automatically
+
+### 🔧 Enterprise Operations
+
+**Everyone gets DevOps excellence:**
+
+```typescript
+// CI/CD and DevOps features
+const brain = new Brainy({
+  operations: {
+    blueGreen: true,                 // Zero-downtime deployments
+    canary: true,                    // Gradual rollouts
+    featureFlags: true,              // Feature toggling
+    migrations: true,                // Automatic migrations
+    versioning: true,                // API versioning
+    rollback: true                   // Instant rollback
+  }
+})
+
+// Same deployment strategies as Google
+```
+
+**Operations features:**
+- **Blue-green deployments**: Zero downtime
+- **Canary releases**: Gradual rollout
+- **Feature flags**: Toggle features instantly
+- **Automatic migrations**: Schema evolution
+- **Version control**: Full history
+- **Instant rollback**: Undo mistakes quickly
+
+## Why Enterprise for Everyone?
+
+### 1. **Democratizing Technology**
+Small teams and individual developers deserve the same powerful tools as large corporations. Innovation shouldn't be limited by budget.
+
+### 2. **No Artificial Limitations**
+We don't cripple our software to create premium tiers. Every limitation in Brainy is technical, not commercial.
+
+### 3. **Community-Driven**
+When everyone has access to enterprise features, the entire community benefits from improvements, bug fixes, and innovations.
+
+### 4. **True Open Source**
+MIT licensed means you can:
+- Use commercially without fees
+- Modify for your needs
+- Contribute improvements
+- Build a business on it
+- Never worry about licensing
+
+### 5. **Future-Proof**
+Your hobby project today might be tomorrow's unicorn startup. With Brainy, you won't need to migrate to "enterprise" software as you grow.
+
+## Real-World Impact
+
+### Startups
+```typescript
+// A 2-person startup gets the same features as Amazon
+const startup = new Brainy()
+// ✓ Full durability
+// ✓ Complete security
+// ✓ Unlimited scale
+// ✓ Zero licensing fees
+```
+
+### Education
+```typescript
+// Students learn with production-grade tools
+const classroom = new Brainy()
+// ✓ No feature restrictions
+// ✓ Real enterprise experience
+// ✓ Free forever
+```
+
+### Non-Profits
+```typescript
+// NGOs get enterprise features without enterprise costs
+const nonprofit = new Brainy()
+// ✓ Compliance tools
+// ✓ Security features
+// ✓ Scale for impact
+// ✓ $0 licensing
+```
+
+### Enterprises
+```typescript
+// Enterprises get everything plus peace of mind
+const enterprise = new Brainy()
+// ✓ Proven at scale
+// ✓ Community tested
+// ✓ No vendor lock-in
+// ✓ Optional support available
+```
+
+## No Compromises
+
+### What you DON'T get with Brainy:
+- ❌ Artificial rate limits
+- ❌ Feature gates
+- ❌ Premium tiers
+- ❌ Usage quotas
+- ❌ Seat licenses
+- ❌ Renewal fees
+- ❌ Vendor lock-in
+- ❌ Proprietary formats
+
+### What you DO get:
+- ✅ Everything
+- ✅ Forever
+- ✅ For free
+- ✅ MIT licensed
+
+## Support Options
+
+While the software is free and complete, we offer optional support:
+
+### Community Support (Free)
+- GitHub Discussions
+- Stack Overflow
+- Discord community
+- Extensive documentation
+
+### Professional Support (Optional)
+- Priority response
+- Architecture review
+- Performance tuning
+- Custom training
+- SLA guarantees
+
+## Getting Started
+
+```bash
+# Install Brainy - get everything immediately
+npm install brainy
+
+# That's it. You now have enterprise-grade AI database
+```
+
+```typescript
+import { Brainy } from 'brainy'
+
+// Create your enterprise-grade database
+const brain = new Brainy()
+await brain.init()
+
+// You're now running the same tech as Fortune 500 companies
+await brain.add("Your data is enterprise-grade", {
+  secure: true,
+  durable: true,
+  scalable: true,
+  free: true
+})
+```
+
+## Comparison
+
+| Feature | Traditional Enterprise DB | Brainy |
+|---------|--------------------------|--------|
+| License Cost | $100k-1M/year | $0 |
+| User Limits | Per seat licensing | Unlimited |
+| Feature Access | Tiered | Everything |
+| Durability | ✅ | ✅ |
+| Security | ✅ | ✅ |
+| Scale | ✅ | ✅ |
+| AI/ML | Additional cost | ✅ Included |
+| Support | Required | Optional |
+| Lock-in | Significant | None |
+| Source Code | Proprietary | MIT Open Source |
+
+## Our Promise
+
+> "Every feature we build goes to everyone. Every optimization benefits all users. Every security enhancement protects the entire community. This is Enterprise for Everyone."
+
+## Join the Revolution
+
+Brainy is more than software—it's a movement to democratize enterprise technology. When everyone has access to the best tools, we all build better things.
+
+**Welcome to enterprise-grade. Welcome to Brainy.**
+
+## See Also
+
+- [Zero Configuration](../architecture/zero-config.md)
+- [Augmentations System](../architecture/augmentations.md)
+- [Architecture Overview](../architecture/overview.md)
+- [API Reference](../api/README.md)

docs/guides/export-and-import.md

@@ -0,0 +1,181 @@
+---
+title: Export & Import (portable graph)
+slug: guides/export-and-import
+public: true
+category: guides
+template: guide
+order: 9
+description: Export part or all of a brain to a portable, versioned PortableGraph document and import it back — by id, collection, connected neighbourhood, VFS subtree, predicate, or the whole brain. export() lives on the immutable Db, so asOf()/with() give time-travel and what-if exports.
+next:
+  - guides/subtypes-and-facets
+  - api/README
+---
+
+# Export & Import (portable graph)
+
+Brainy serializes part or all of a brain — an item, a collection, a connected
+neighbourhood, a VFS subtree, a predicate match, or the whole brain — into a single
+versioned JSON document (`PortableGraph`), and restores it.
+
+```typescript
+const graph = await brain.export()   // whole brain → PortableGraph
+await brain.import(graph)             // restore (merge by id, re-embed if no vectors)
+```
+
+It is **portable** (human-readable JSON), **versioned** (`formatVersion`, so a document
+written by 7.x imports cleanly into 8.0), and **current-state** (the entities and edges as
+they are now — no generation history). Use it for portable artifacts, partial exports,
+cross-environment moves, and version upgrades.
+
+`export()` is a method on the **immutable `Db` value**, so it composes with every way of
+obtaining one:
+
+```typescript
+brain.export(sel)                                   // = brain.now().export(sel)
+;(await brain.asOf(gen)).export(sel)                // time-travel export (a past generation)
+brain.now().with(ops).export(sel)                   // what-if export (a speculative state)
+```
+
+## When to use which
+
+| You want… | Use |
+|-----------|-----|
+| A portable, partial-or-whole, cross-version graph document | **`brain.export()` / `brain.import()`** (this guide) |
+| A whole-brain snapshot **with generation history** | `brain.now().persist(path)` / `Brainy.load(path)` (native) |
+| To ingest a CSV / PDF / Excel / JSON **file** as new entities | `brain.import(file)` — see [Import Anything](./import-anything.md) |
+
+`import()` is **polymorphic**: hand it a `PortableGraph` and it does the graph round-trip;
+hand it a file/buffer and it does foreign-file ingestion (dispatched on the document's
+`format: 'brainy-portable-graph'` tag).
+
+## Exporting
+
+```typescript
+brain.export(selector?, options?): Promise<PortableGraph>
+// (also on any Db: brain.now().export(...), (await brain.asOf(g)).export(...))
+```
+
+### Selectors — *what* to export
+
+Omit the selector to export the whole brain. Otherwise pick a node set:
+
+| Scenario | Selector |
+|----------|----------|
+| Just an item (or items) | `{ ids: ['a', 'b'] }` |
+| A collection + its children | `{ collection: collectionId }` (alias `memberOf`) |
+| A connected neighbourhood | `{ connected: { from: id, depth: 2, verbs?, direction? } }` |
+| A VFS directory / file (+ subtree) | `{ vfsPath: '/docs', recursive?: true }` |
+| Everything matching a predicate | `{ type, subtype, where, service, visibility }` |
+| The whole brain | *(omit)* |
+
+The selector reuses `find()`'s grammar — *"export what `find()` would match, minus ranking
+and limit."* Structural and predicate selectors **compose**:
+
+```typescript
+// Members of a collection whose status is "open"
+await brain.export({ collection: collectionId, where: { status: 'open' } })
+
+// Already have find() results? Export exactly those with the ids selector
+const hits = await brain.find({ type: NounType.Document })
+await brain.export({ ids: hits.map(r => r.id) })
+```
+
+### Options — *how* to serialize
+
+| Option | Default | Effect |
+|--------|---------|--------|
+| `includeVectors` | `false` | Carry embedding vectors verbatim. Off ⇒ `import()` re-embeds from `data`. |
+| `includeContent` | `false` | Include VFS file bytes in `blobs` so files round-trip byte-identically. |
+| `includeSystem` | `false` | Include `visibility:'system'` entities such as the VFS root. |
+| `edges` | `'induced'` | `'induced'` (both endpoints in the set), `'incident'` (also dangling edges, recorded in `danglingIds`), or `'none'` (nodes only). |
+
+## Importing
+
+```typescript
+brain.import(graph, options?): Promise<ImportResult>
+```
+
+The whole graph is applied as **one atomic transaction** — it advances the brain exactly
+one generation, or none on failure.
+
+```typescript
+const result = await brain.import(graph, { onConflict: 'merge' })
+// → { imported, merged, skipped, reembedded, blobsWritten, errors }
+```
+
+| Option | Default | Effect |
+|--------|---------|--------|
+| `onConflict` | `'merge'` | `'merge'` (update existing id in place — assemble many exported graphs), `'replace'` (delete + recreate), or `'skip'`. |
+| `reembed` | `'auto'` | `'auto'` (use the carried vector, else re-embed from `data`) or `'never'` (require a carried vector; record an error if absent). |
+| `remapIds` | — | Rewrite every id on the way in, e.g. to clone a template subgraph under fresh ids. |
+| `meta` | — | Transaction metadata recorded in the tx-log alongside the new generation. |
+
+The default `onConflict: 'merge'` lets you assemble one working graph from many exported
+documents that share entity ids — re-importing an id merges rather than duplicates.
+
+## The `PortableGraph` format
+
+```jsonc
+{
+  "format": "brainy-portable-graph",  // identifies the document type
+  "formatVersion": 1,                 // import gates on this (cross-version migration)
+  "brainyVersion": "8.0.0",
+  "createdAt": "2026-06-16T…Z",
+  "embedding": { "model": "all-MiniLM-L6-v2", "dimensions": 384 },
+  "selector": { … },                  // echoes what was exported (provenance)
+  "entities": [
+    {
+      "id": "…", "type": "Document", "subtype": "invoice", "visibility": "public",
+      "data": "…",                    // the embedding source
+      "confidence": 1, "weight": 1, "service": "…",
+      "vector": [ … ],                // only with includeVectors
+      "metadata": { … }               // custom fields only (reserved fields are top-level)
+    }
+  ],
+  "relations": [
+    { "id":"…", "from":"…", "to":"…", "type":"Contains", "subtype":"…",
+      "weight":1, "confidence":1, "metadata": { … } }
+  ],
+  "blobs": { "<sha256>": "<base64>" }, // only with includeContent
+  "danglingIds": [ "…" ],             // only with edges:'incident'
+  "stats": { "entityCount": 0, "relationCount": 0, "blobCount": 0, "vectorDimensions": 384 }
+}
+```
+
+Standard fields (`subtype`, `visibility`, `data`, `confidence`, `weight`, `service`) sit at
+the top level of each entity; `metadata` holds **only** custom user fields — mirroring the
+in-memory `Entity` shape, so `import()` maps each field to its dedicated parameter. The
+TypeScript types (`PortableGraph`, `PortableGraphEntity`, `PortableGraphRelation`, `ExportSelector`,
+`ExportOptions`, `ImportOptions`, `ImportResult`) are exported from the package root.
+
+## Generations & time-travel
+
+The portable document is **current-state** — it never embeds generation history (that keeps
+it cross-version-portable). History lives where it's queryable:
+
+- **During a session:** `brain.asOf(g)` / `brain.now().with(ops)` on the live brain. Because
+  `export()` is on the `Db`, `(await brain.asOf(g)).export()` serializes a *past* generation
+  and `brain.now().with(ops).export()` serializes a *speculative* one.
+- **A whole-brain snapshot with history:** `brain.now().persist(path)` / `Brainy.load(path)`
+  (native, generation-preserving) — a separate facility from this portable format.
+
+Note: only `transact()` (and the write shortcuts that commit through it) advances a
+generation, so time-travel export differs across transaction boundaries.
+
+## Cross-version (7.x → 8.0)
+
+Because the document is shared and versioned, a PortableGraph written by 7.x imports into 8.0:
+`formatVersion` is read forward, `subtype` is carried so 8.0 re-types correctly, and the
+same 384-dimension model on both lines means `includeVectors:false` re-embeds identically
+(or `true` carries vectors verbatim).
+
+## VFS
+
+VFS directories are `Collection` entities and files are entities linked by `Contains`, so
+the whole filesystem (or any subtree) exports through the `vfsPath` selector:
+
+```typescript
+await brain.export({ vfsPath: '/' },        { includeContent: true }) // all VFS + bytes
+await brain.export({ vfsPath: '/docs' },    { includeContent: true }) // one directory
+await brain.export({ vfsPath: '/a/b.txt' }, { includeContent: true }) // one file
+```