# 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.