docs: rename the native provider to @soulcraft/cor across public docs and JSDoc

The 3.0 native engine ships as @soulcraft/cor (brainy 8.x <-> cor 3.x are a
version-matched pair); the old @soulcraft/cortex package stays on the 2.x/7.x
line. Public docs and .d.ts-visible comments now name the correct package.
Historical 2.x contract references (e.g. the 2.3.1 read-side fallback) keep
the old name deliberately.

docs/PERFORMANCE.md

@@ -417,7 +417,7 @@ const brain = new Brainy({
 })
 ```
 
-The default JS index is `JsHnswVectorIndex`. An optional native acceleration package (`@soulcraft/cortex`) can replace it with a higher-performing implementation; the public knobs stay the same.
+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
 

docs/PLUGINS.md

@@ -12,7 +12,7 @@ next:
 
 # Plugin Development Guide
 
-Brainy has a plugin system that allows third-party packages to replace internal subsystems with custom implementations. This is how `@soulcraft/cortex` provides optional native acceleration, and it's the same system available to any developer.
+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
 
@@ -27,7 +27,7 @@ Plugins are **opt-in** — brainy never auto-imports packages. You must explicit
 
 ```typescript
 const brain = new Brainy({
-  plugins: ['@soulcraft/cortex']  // explicitly load the native acceleration package
+  plugins: ['@soulcraft/cor']  // explicitly load the native acceleration package
 })
 ```
 
@@ -36,7 +36,7 @@ const brain = new Brainy({
 | `undefined` (default) | No plugins loaded |
 | `false` | No plugins loaded |
 | `[]` | No plugins loaded |
-| `['@soulcraft/cortex']` | Load only the listed packages |
+| `['@soulcraft/cor']` | Load only the listed packages |
 
 Plugins registered programmatically via `brain.use(plugin)` are always activated regardless of the `plugins` config.
 
@@ -215,7 +215,7 @@ context.registerProvider('aggregation', (storage) => {
 })
 ```
 
-When provided by an optional native acceleration plugin (such as `@soulcraft/cortex`), this enables:
+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
@@ -251,7 +251,7 @@ 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/cortex`) is installed.
+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.
 
@@ -359,8 +359,8 @@ brainy diagnostics
 When a plugin is active, brainy automatically logs a provider summary after `init()`:
 
 ```
-[brainy] Plugin activated: @soulcraft/cortex
+[brainy] Plugin activated: @soulcraft/cor
-[brainy] Providers: 8/10 native (@soulcraft/cortex) | default: vector, cache
+[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`.
@@ -381,7 +381,7 @@ If a required provider is missing, the error message tells you exactly what's wr
 
 ```
 [brainy] Required providers using JS fallback: graphIndex.
-Active plugins: @soulcraft/cortex.
+Active plugins: @soulcraft/cor.
 These providers must be supplied by a plugin for this deployment.
 Check plugin installation, license, and native module availability.
 ```

docs/QUERY_OPERATORS.md

@@ -234,7 +234,7 @@ const all = await brain.related({
 })
 
 // Graph traversal — subtype filters traversal edges (depth-1 in 7.30 JS path;
-// multi-hop subtype filtering lands on Cortex native)
+// multi-hop subtype filtering lands on Cor native)
 const reports = await brain.find({
   connected: {
     from: ceoId,

docs/SCALING.md

@@ -37,7 +37,7 @@ 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/cortex` package) extends this with a higher-performing index — and its own at-scale acceleration such as on-disk compressed indexing — when installed.
+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
 
@@ -77,7 +77,7 @@ 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/cortex`, on-disk DiskANN) — same API, no code change. _Projected from
+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._
 
@@ -213,12 +213,12 @@ const stats = await brain.stats()
 ### 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/cortex`
+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/cortex` for at-scale index acceleration
+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

docs/architecture/aggregation.md

@@ -33,7 +33,7 @@
 │             ▼                                            │
 │  ┌──────────────────────┐                                │
 │  │  AggregationProvider │  (optional, registered by      │
-│  │  ├─ incrementalUpdate│   plugin like @soulcraft/cortex)│
+│  │  ├─ incrementalUpdate│   plugin like @soulcraft/cor)   │
 │  │  ├─ rebuildAggregate │                                │
 │  │  ├─ queryAggregate   │                                │
 │  │  └─ serialize/restore│                                │
@@ -135,7 +135,7 @@ M2 is clamped to zero on remove to prevent floating-point drift from producing n
 
 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 Cortex 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.
+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
 

docs/architecture/index-architecture.md

@@ -402,7 +402,7 @@ const DEFAULT_EXCLUDE_FIELDS = [
 
 **Purpose**: O(log n) semantic similarity search using vector embeddings.
 
-The default JS implementation is `JsHnswVectorIndex`; an optional native acceleration package (`@soulcraft/cortex`) can register a higher-performing `VectorIndexProvider` through the plugin system. The public API stays the same either way.
+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
 

docs/architecture/multiprocess-storage-mixin.md

@@ -22,7 +22,7 @@ requestFlushOverFilesystem(timeoutMs)
 
 They live on `BaseStorage` as no-op defaults and are overridden on
 `FileSystemStorage` with real implementations. Any adapter extending
-`FileSystemStorage` (e.g. Cortex's `MmapFileSystemStorage`) inherits the
+`FileSystemStorage` (e.g. Cor's `MmapFileSystemStorage`) inherits the
 real ones for free.
 
 This works correctly today. The question is whether the methods *belong*
@@ -83,7 +83,7 @@ Benefits:
 ## The case against doing it now
 
 - Breaking change for any adapter that already overrides these methods.
-  `FileSystemStorage` is the only one in-tree, but Cortex's
+  `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

docs/architecture/overview.md

@@ -48,7 +48,7 @@ Pluggable vector index (`VectorIndexProvider`) for efficient nearest-neighbor se
 - **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/cortex`) via the plugin system without changing application code
+- **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:

docs/architecture/zero-config.md

@@ -84,7 +84,7 @@ const brain = new Brainy({
 ```
 
 The default JS index is `JsHnswVectorIndex`. An optional native acceleration
-provider (the `@soulcraft/cortex` package) can replace it with a
+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.

docs/concepts/multi-process.md

@@ -55,20 +55,20 @@ process opening the same directory:
 The fix is the lock: refuse to open a second writer. SQLite has done the same
 since the late 1990s (`SQLITE_BUSY`).
 
-## What about Cortex?
+## What about Cor?
 
-Brainy + Cortex compose cleanly under this model:
+Brainy + Cor compose cleanly under this model:
 
-- Cortex stores its column-index segments inside the same `rootDir` (under
+- Cor stores its column-index segments inside the same `rootDir` (under
   `indexes/_column_index/{field}/`).
-- Segments (`*.cidx` files) are **immutable** once written. Cortex mmaps them
+- 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 Cortex segments alongside a live writer
+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 Cortex too, because Cortex segment
+`<rootDir>/locks/_writer.lock` covers Cor too, because Cor segment
 writes happen on the writer's side.
 
 ## Stale-lock detection
@@ -141,7 +141,7 @@ The CLI `brainy inspect` subcommands all do this for you by default
   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 Cortex segments
+- **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.
@@ -150,4 +150,4 @@ The CLI `brainy inspect` subcommands all do this for you by default
 
 - `Brainy.openReadOnly()` — [API reference](../api/brainy.md)
 - `brainy inspect` — [inspection guide](../guides/inspection.md)
-- Cortex columnar storage — see `node_modules/@soulcraft/cortex/README.md`
+- Cor columnar storage — see `node_modules/@soulcraft/cor/README.md`

docs/concepts/storage-adapters.md

@@ -33,7 +33,7 @@ BaseStorage                (type-statistics, lifecycle helpers, generation
 FileSystemStorage          (real filesystem I/O, writer-lock implementation,
                             flush-request watcher, atomic writes)
         ↑
-<your plugin's storage>    (Cortex's MmapFileSystemStorage, etc.)
+<your plugin's storage>    (Cor's MmapFileSystemStorage, etc.)
 ```
 
 When you `extend FileSystemStorage`, your adapter inherits every method on

docs/eli5.md

@@ -11,7 +11,7 @@ next:
   - getting-started/quick-start
 ---
 
-# Brainy and Cortex — Explained Simply
+# Brainy and Cor — Explained Simply
 
 *A plain-language guide for anyone who wants to understand what this thing actually does.*
 
@@ -65,13 +65,13 @@ Brainy can narrow any result set down by exact labels or ranges in the same brea
 
 ---
 
-## What is Cortex?
+## What is Cor?
 
-Cortex is a turbocharger for Brainy.
+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, Cortex 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.
+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.
 
@@ -83,9 +83,9 @@ 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 Cortex brings the native capabilities required to run them efficiently.
+- **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, Cortex is what makes Brainy feel instant.
+If Brainy is what makes knowledge fast, Cor is what makes Brainy feel instant.
 
 ---
 
@@ -135,7 +135,7 @@ Brainy is the only row with every box checked. And it runs all of them in a sing
 
 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 Cortex 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.
+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.
 
 ---
 

docs/guides/aggregation.md

@@ -487,7 +487,7 @@ Aggregate definitions and running state are automatically persisted:
 
 ## Native Acceleration
 
-When [Cortex](https://github.com/soulcraftlabs/cortex) is installed as a plugin, the aggregation engine automatically uses Rust-accelerated computation:
+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
@@ -496,7 +496,7 @@ When [Cortex](https://github.com/soulcraftlabs/cortex) is installed as a plugin,
 
 ```typescript
 const brain = new Brainy({
-  plugins: ['@soulcraft/cortex']
+  plugins: ['@soulcraft/cor']
 })
 await brain.init()
 
@@ -577,7 +577,7 @@ brain.defineAggregate({
 
 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 Cortex native acceleration:
+With Cor native acceleration:
 
 | Operation | Throughput | Latency |
 |-----------|-----------|---------|

docs/guides/enterprise-for-everyone.md

@@ -174,13 +174,13 @@ await brain.syncWith({
 const brain = new Brainy()
 
 // 1 → ~1M vectors: pure-JS HNSW, zero extra setup
-// 1M → 10B+ vectors: install @soulcraft/cortex for the native DiskANN provider
+// 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/cortex` to back the index with
+- **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

docs/guides/installation.md

@@ -45,20 +45,20 @@ console.log('Brainy ready.')
 
 ## Native Acceleration (Optional)
 
-For production workloads, add Cortex for Rust-accelerated SIMD distance calculations and native embeddings:
+For production workloads, add Cor for Rust-accelerated SIMD distance calculations and native embeddings:
 
 ```bash
-npm install @soulcraft/cortex
+npm install @soulcraft/cor
 ```
 
 ```typescript
 import { Brainy } from '@soulcraft/brainy'
 
-const brain = new Brainy({ plugins: ['@soulcraft/cortex'] })
+const brain = new Brainy({ plugins: ['@soulcraft/cor'] })
 await brain.init()  // native providers registered during init
 ```
 
-Cortex registers native (Rust/SIMD) vector, metadata, and graph engines behind the same Brainy `find()` API — no code changes, an optional dependency for production-scale workloads.
+Cor registers native (Rust/SIMD) vector, metadata, and graph engines behind the same Brainy `find()` API — no code changes, an optional dependency for production-scale workloads.
 
 ## Server-only since 8.0
 

docs/guides/subtypes-and-facets.md

@@ -332,7 +332,7 @@ await brain.updateRelation({ id: relationId, weight: 0.5, confidence: 0.9 })
 `find({ connected, subtype })` filters traversal edges by their subtype. Composes with `via` (verb-type filter):
 
 ```typescript
-// All direct reports two hops deep (will be supported in Cortex; for now depth-1)
+// All direct reports two hops deep (will be supported in Cor; for now depth-1)
 const directChain = await brain.find({
   connected: {
     from: ceoId,
@@ -343,7 +343,7 @@ const directChain = await brain.find({
 })
 ```
 
-Multi-hop subtype filtering (`depth > 1`) lights up on the Cortex native path; the JS path throws today rather than return incorrect partial results.
+Multi-hop subtype filtering (`depth > 1`) lights up on the Cor native path; the JS path throws today rather than return incorrect partial results.
 
 ### Counts
 

src/aggregation/AggregationIndex.ts

@@ -269,7 +269,7 @@ function recomputeMinMaxFromCounts(state: MetricState): void {
 /**
  * Exact percentile over a value multiset, using linear interpolation between closest ranks
  * (numpy 'linear' / type-7): `rank = p·(n−1)`, interpolating between the floor and ceil
- * positions of the sorted expansion. Mirrors Cortex's `MetricState::percentile` bit-for-bit.
+ * positions of the sorted expansion. Mirrors Cor's `MetricState::percentile` bit-for-bit.
  */
 function computePercentile(valueCounts: Record<string, number>, count: number, p: number): number {
   if (count === 0) return 0

src/brainy.ts

@@ -635,13 +635,13 @@ export class Brainy<T = any> implements BrainyInterface<T> {
    * Whether the active storage adapter (anywhere in its prototype chain)
    * implements a given optional method.
    *
-   * Storage-adapter plugins (e.g. `@soulcraft/cortex`'s `MmapFileSystemStorage
+   * Storage-adapter plugins (e.g. `@soulcraft/cor`'s `MmapFileSystemStorage
    * extends FileSystemStorage`) inherit new methods Brainy adds to
    * `FileSystemStorage` / `BaseStorage` automatically — `typeof` walks the
    * prototype chain, so there's no in-package version skew to worry about as
    * long as the plugin's own dist resolves `@soulcraft/brainy` dynamically
    * (which Cortex 2.2.x onward does — see
-   * `node_modules/@soulcraft/cortex/dist/storage/mmapFileSystemStorage.js`).
+   * `node_modules/@soulcraft/cor/dist/storage/mmapFileSystemStorage.js`).
    *
    * This helper exists for the **build/install** failure modes the import
    * resolution can't catch:
@@ -776,7 +776,7 @@ export class Brainy<T = any> implements BrainyInterface<T> {
 
     try {
       // Auto-detect and activate plugins BEFORE storage setup
-      // so plugin-provided storage factories (e.g., filesystem override from cortex) are available
+      // so plugin-provided storage factories (e.g., filesystem override from cor) are available
       await this.loadPlugins()
 
       // 7.x → 8.0 layout migration, BEFORE storage setup: collapse a legacy
@@ -793,7 +793,7 @@ export class Brainy<T = any> implements BrainyInterface<T> {
       // Skipped in reader mode and on backends that don't support multi-process locking.
       // Throws if another live writer holds the directory (unless force: true).
       //
-      // Defensive call: older storage adapters (e.g. `@soulcraft/cortex@2.2.0`
+      // Defensive call: older storage adapters (e.g. `@soulcraft/cor@2.2.0`
       // and earlier) bundle a pre-7.21 `BaseStorage` that doesn't define these
       // methods. We feature-detect each one rather than fail boot.
       if (this.config.mode !== 'reader') {
@@ -900,7 +900,7 @@ export class Brainy<T = any> implements BrainyInterface<T> {
         setMsgpackImplementation(msgpackProvider)
       }
 
-      // Provider: sort:topK (e.g. cortex's native partial-sort / heap-select) — swaps the
+      // Provider: sort:topK (e.g. cor's native partial-sort / heap-select) — swaps the
       // JS result-ranking used by find() to pick the top `offset + limit` rows. The provider
       // returns indices into a scores array, ordered descending with stable ties, identical
       // to the JS sortTopKIndicesJs. rankIndicesByScore validates the provider's output and
@@ -927,7 +927,7 @@ export class Brainy<T = any> implements BrainyInterface<T> {
       if (metadataFactory) {
         this.metadataIndex = metadataFactory(this.storage)
       } else {
-        // JS fallback — inject native EntityIdMapper if cortex provides one
+        // JS fallback — inject native EntityIdMapper if cor provides one
         const entityIdMapperFactory = this.pluginRegistry.getProvider<(storage: StorageAdapter) => any>('entityIdMapper')
         this.metadataIndex = new MetadataIndexManager(this.storage, {}, {
           entityIdMapper: entityIdMapperFactory ? entityIdMapperFactory(this.storage) : undefined,
@@ -9756,7 +9756,7 @@ export class Brainy<T = any> implements BrainyInterface<T> {
   /**
    * Assert that specific providers are supplied by a plugin (not using JS fallback).
    *
-   * Call after init() in production to fail fast if a paid plugin (e.g. cortex)
+   * Call after init() in production to fail fast if a paid plugin (e.g. cor)
    * isn't providing the expected acceleration. Throws if any listed key is using
    * the default JavaScript implementation.
    *
@@ -9768,7 +9768,7 @@ export class Brainy<T = any> implements BrainyInterface<T> {
    * const brain = new Brainy()
    * await brain.init()
    *
-   * // Fail fast if cortex isn't providing these
+   * // Fail fast if cor isn't providing these
    * brain.requireProviders(['distance', 'embeddings', 'metadataIndex', 'graphIndex'])
    * ```
    */
@@ -13274,7 +13274,7 @@ export class Brainy<T = any> implements BrainyInterface<T> {
 
   /**
    * @description Wire the HNSW connections codec (2.4.0 #3). Activates when
-   * BOTH (a) the `graph:compression` provider is registered (cortex registers
+   * BOTH (a) the `graph:compression` provider is registered (cor registers
    * `{ encode: encodeConnections, decode: decodeConnections }`), and (b) the
    * metadata index exposes a stable idMapper. Failures are non-fatal: HNSW
    * keeps working via the legacy JSON-array path.
@@ -14024,7 +14024,7 @@ export class Brainy<T = any> implements BrainyInterface<T> {
    * case under durable storage, where a brain reopens pre-populated — would otherwise
    * return `[]`. On first query we clear the aggregate's state and stream every stored
    * noun back through it. Storage-agnostic: `getNouns()` works for in-memory, the
-   * filesystem adapter, and native (Cortex) storage alike. One-time per definition —
+   * filesystem adapter, and native (Cor) storage alike. One-time per definition —
    * the rebuilt state is persisted on flush() and reloaded on the next session.
    */
   private async backfillAggregateIfNeeded(name: string): Promise<void> {
@@ -14074,7 +14074,7 @@ export class Brainy<T = any> implements BrainyInterface<T> {
     await this.autoCompactHistory()
 
     // Phase 1: Flush ALL components in parallel to persist buffered data
-    // This is critical when cortex native providers buffer data in Rust memory
+    // This is critical when cor native providers buffer data in Rust memory
     await Promise.all([
       // Flush HNSW dirty nodes (deferred persistence mode)
       (async () => {

src/embeddings/EmbeddingManager.ts

@@ -60,7 +60,7 @@ export class EmbeddingManager {
   private constructor() {
     this.engine = WASMEmbeddingEngine.getInstance()
     // Log deferred to init() — at construction time we don't know if a plugin
-    // (like Cortex) will replace the WASM embedder with a native one.
+    // (like Cor) will replace the WASM embedder with a native one.
   }
 
   /**

src/graph/lsm/SSTable.ts

@@ -20,13 +20,13 @@ import { BloomFilter, SerializedBloomFilter } from './BloomFilter.js'
 import { compareCodePoints } from '../../utils/collation.js'
 
 // Swappable msgpack implementation — defaults to @msgpack/msgpack JS,
-// can be replaced with native msgpack (e.g., cortex's Rust-backed encoder)
+// can be replaced with native msgpack (e.g., cor's Rust-backed encoder)
 let _encode: (data: unknown) => Uint8Array = defaultEncode as (data: unknown) => Uint8Array
 let _decode: (data: Uint8Array) => unknown = defaultDecode as (data: Uint8Array) => unknown
 
 /**
  * Replace the msgpack encode/decode implementation at runtime.
- * Called by brainy.ts when a cortex 'msgpack' provider is registered.
+ * Called by brainy.ts when a cor 'msgpack' provider is registered.
  */
 export function setMsgpackImplementation(impl: { encode: (data: unknown) => Uint8Array, decode: (data: Uint8Array) => unknown }) {
   _encode = impl.encode

src/hnsw/connectionsCodec.ts

@@ -1,7 +1,7 @@
 /**
  * @module hnsw/connectionsCodec
  * @description Bridge between brainy's UUID-keyed HNSW connection sets and
- * cortex's int-keyed delta-varint encode/decode (the `graph:compression`
+ * cor's int-keyed delta-varint encode/decode (the `graph:compression`
  * provider). Translates UUIDs to stable int slots via the post-2.4.0 #1
  * `EntityIdMapper`, batches all of a node's per-level connection lists into
  * a single compact buffer, and reverses the path on load.
@@ -130,7 +130,7 @@ export class ConnectionsCodec {
  * @description Build the binary-blob storage key for a node's compressed
  * connections. Suffix-free; the adapter appends its own. Keys live under
  * `_hnsw_conn/` so they don't collide with the existing `_column_index/`
- * blobs and so a cortex-side reader knows exactly where to look.
+ * blobs and so a cor-side reader knows exactly where to look.
  */
 export function compressedConnectionsKey(nodeId: string): string {
   return `_hnsw_conn/${nodeId}`

src/index.ts

@@ -6,7 +6,7 @@
  * - Brainy: The unified database with Triple Intelligence
  * - Triple Intelligence: Seamless fusion of vector + graph + field search
  * - Db: Immutable, generation-pinned database values (now/transact/asOf/with)
- * - Plugins: Extensible plugin system (cortex, storage adapters)
+ * - Plugins: Extensible plugin system (cor, storage adapters)
  * - Neural Import: AI-powered entity extraction & smart data import
  */
 

src/indexes/columnStore/ColumnSegmentCursor.ts

@@ -7,7 +7,7 @@
  * Multiple cursors can read the same segment concurrently (e.g. during k-way merge).
  *
  * For the TS baseline, segments are loaded fully into memory and cached via
- * UnifiedCache. The Cortex Rust implementation mmaps the segment file and
+ * UnifiedCache. The Cor Rust implementation mmaps the segment file and
  * indexes into it directly — same read interface, zero-copy access.
  */
 

src/indexes/columnStore/ColumnStore.ts

@@ -476,9 +476,9 @@ export class ColumnStore implements ColumnStoreProvider {
    * Storage path (2.4.0 #4 / cortex-interchange contract):
    *   When the storage adapter exposes the binary-blob primitive
    *   (`saveBinaryBlob` — every brainy adapter ≥7.25.0 does), the segment
-   *   bytes are written as a raw blob at the shared cortex key
+   *   bytes are written as a raw blob at the shared cor key
    *   `_column_index/<field>/L<level>-NNNNNN` (suffix-free; the adapter
-   *   appends its own). This matches byte-for-byte what cortex's
+   *   appends its own). This matches byte-for-byte what cor's
    *   `NativeColumnStore` writes, so JS- and native-written indexes
    *   interchange without re-encoding.
    *
@@ -522,7 +522,7 @@ export class ColumnStore implements ColumnStoreProvider {
       )
 
       if (canUseBlob) {
-        // Raw blob, cortex-shared key convention.
+        // Raw blob, cor-shared key convention.
         const key = `${this.basePath}/${field}/L0-${String(segId).padStart(6, '0')}`
         await storage.saveBinaryBlob!(key, segBuffer)
       } else {
@@ -561,7 +561,7 @@ export class ColumnStore implements ColumnStoreProvider {
     }
 
     // Persist the global deleted bitmap alongside the manifest. Same
-    // raw-blob preference as segments — shared cortex key `<base>/<field>/DELETED`.
+    // raw-blob preference as segments — shared cor key `<base>/<field>/DELETED`.
     const deleted = this.deletedEntities.get(field)
     if (deleted && deleted.size > 0) {
       const serialized = deleted.serialize(true)
@@ -627,7 +627,7 @@ export class ColumnStore implements ColumnStoreProvider {
         readObjectFromPath: (path: string) => Promise<any>
       }
 
-      // Preferred: raw blob at the cortex-shared key.
+      // Preferred: raw blob at the cor-shared key.
       if (typeof storage.loadBinaryBlob === 'function') {
         const key = `${this.basePath}/${field}/L${seg.level}-${String(seg.id).padStart(6, '0')}`
         const blob = await storage.loadBinaryBlob(key)

src/indexes/columnStore/types.ts

@@ -168,7 +168,7 @@ export const FLAG_MULTI_VALUE = 0x01
  * The plugin-provider contract for the column store.
  *
  * Brainy ships a TypeScript baseline that implements this interface.
- * Cortex registers a Rust-accelerated implementation at higher priority.
+ * Cor registers a Rust-accelerated implementation at higher priority.
  * The MetadataIndex coordinator calls whichever is registered.
  *
  * **8.0 u64 contract — BigInt entity ints at the boundary.** Entity ints flow

src/internals.ts

@@ -16,6 +16,6 @@ export type { EntityIdMapperOptions, EntityIdMapperData } from './utils/entityId
 export { getRecommendedCacheConfig, formatBytes, checkMemoryPressure } from './utils/memoryDetection.js'
 export type { MemoryInfo, CacheAllocationStrategy } from './utils/memoryDetection.js'
 // Entity field resolution — single source of truth for reading fields off
-// HNSWNounWithMetadata. First-party plugins (Cortex) use this to stay in
+// HNSWNounWithMetadata. First-party plugins (Cor) use this to stay in
 // lockstep with the entity shape contract.
 export { resolveEntityField, STANDARD_ENTITY_FIELDS } from './coreTypes.js'

src/neural/embeddedPatterns.ts

@@ -2,7 +2,7 @@
  * 🧠 BRAINY EMBEDDED PATTERNS
  * 
  * AUTO-GENERATED - DO NOT EDIT
- * Generated: 2026-06-11T21:32:56.112Z
+ * Generated: 2026-07-02T21:43:26.976Z
  * Patterns: 220
  * Coverage: 94-98% of all queries
  * 

src/plugin.ts

@@ -2,7 +2,7 @@
  * Brainy Plugin System
  *
  * Simple plugin architecture for two use cases:
- * 1. Native acceleration (@soulcraft/cortex)
+ * 1. Native acceleration (@soulcraft/cor)
  * 2. Custom storage adapters (e.g., Redis, DynamoDB, custom backends)
  *
  * Plugins are loaded from an explicit `plugins: [...]` config list or
@@ -20,7 +20,7 @@ import type { MetadataIndexStats } from './utils/metadataIndex.js'
 import type { GraphIndexStats } from './graph/graphAdjacencyIndex.js'
 
 // Re-export the provider contracts that already live closer to their
-// implementations so a plugin author (Cortex) can import the *entire*
+// implementations so a plugin author (Cor) can import the *entire*
 // provider surface from one stable entrypoint: `@soulcraft/brainy/plugin`.
 export type { ColumnStoreProvider } from './indexes/columnStore/types.js'
 export type {
@@ -75,7 +75,7 @@ export interface BrainyPluginContext {
   /**
    * Register a provider for a named subsystem.
    *
-   * Well-known provider keys (used by cortex):
+   * Well-known provider keys (used by cor):
    * - 'metadataIndex'      — MetadataIndexManager replacement
    * - 'graphIndex'         — GraphAdjacencyIndex replacement
    * - 'entityIdMapper'     — EntityIdMapper replacement
@@ -103,7 +103,7 @@ export interface BrainyPluginContext {
 //
 // These interfaces are the type-level half of the provider-parity guarantee.
 // They capture only what Brainy actually invokes, so a native accelerator
-// (Cortex) that declares `implements MetadataIndexProvider` gets a compile
+// (Cor) that declares `implements MetadataIndexProvider` gets a compile
 // error the moment a method Brainy depends on is dropped or its signature
 // drifts. Brainy's own baseline classes (`MetadataIndexManager`,
 // `GraphAdjacencyIndex`, `JsHnswVectorIndex`, `EntityIdMapper`, `UnifiedCache`)
@@ -840,7 +840,7 @@ export interface AtGenerationVectors {
 /**
  * The object returned by the `'vector'` provider factory — Brainy's vector
  * index contract. Implementations include Brainy's own JS HNSW index and any
- * native acceleration provider (e.g. cortex's Adaptive DiskANN).
+ * native acceleration provider (e.g. cor's Adaptive DiskANN).
  *
  * Brainy calls this surface via `this.index.*` plus the transactional add/remove
  * operations. `enableCOW`, `getItem`, and `setPersistMode` are intentionally
@@ -980,7 +980,7 @@ export interface CacheProvider {
 
 /**
  * The `'graph:compression'` provider — pure-function encode/decode for HNSW
- * connection lists as compact delta-varint byte sequences (cortex's
+ * connection lists as compact delta-varint byte sequences (cor's
  * `encodeConnections` / `decodeConnections`).
  *
  * Brainy's `JsHnswVectorIndex` consumes this via a `ConnectionsCodec` that translates

src/storage/adapters/baseStorageAdapter.ts

@@ -61,7 +61,7 @@ export abstract class BaseStorageAdapter implements StorageAdapter {
 
   // Vector Index Persistence (Brainy 8.0 — algorithm-neutral surface).
   // Concrete adapters persist the per-entity HNSW graph node (level + connections)
-  // under these methods. Cortex's DiskANN-style native vector index doesn't use
+  // under these methods. Cor's DiskANN-style native vector index doesn't use
   // them (it persists its own single mmap'd `.dkann` file under
   // `_system/vector-index/<shard>.dkann` per BRAINY-8.0-RENAME-COORDINATION § B.2).
 

src/storage/adapters/fileSystemStorage.ts

@@ -1251,7 +1251,7 @@ export class FileSystemStorage extends BaseStorage {
    * The key's "/"-separated segments become nested directories and the file is
    * suffixed with `.bin`, e.g. `"graph-lsm/source/sstable-123"` →
    * `<rootDir>/_blobs/graph-lsm/source/sstable-123.bin`. This convention is
-   * shared with cortex's `MmapFileSystemStorage` so native code and the TS layer
+   * shared with cor's `MmapFileSystemStorage` so native code and the TS layer
    * agree on exactly where each blob lives.
    *
    * @param key - The blob key.

src/types/brainy.types.ts

@@ -1384,7 +1384,7 @@ export interface MetricState {
   /**
    * Value multiset (String(value) → occurrence count) for exact percentile + distinctCount.
    * Maintained only for `percentile`/`distinctCount` metrics. JSON-serializable; mirrors
-   * Cortex's `value_counts` so JS and native agree bit-for-bit.
+   * Cor's `value_counts` so JS and native agree bit-for-bit.
    */
   valueCounts?: Record<string, number>
 }
@@ -1443,7 +1443,7 @@ export interface AggregateResult {
 }
 
 /**
- * Provider interface for Cortex-accelerated aggregation.
+ * Provider interface for Cor-accelerated aggregation.
  * When registered as 'aggregation' provider, Brainy delegates to this.
  */
 export interface AggregationProvider {
@@ -1699,7 +1699,7 @@ export interface BrainyConfig {
    * byte-for-byte so a `'balanced'`-default upgrade is a no-op.
    *
    * **Closed-form contract** locked in handoff thread
-   * BRAINY-8.0-RENAME-COORDINATION § A.2 + § G.2 (cortex-confirmed 2026-06-09).
+   * BRAINY-8.0-RENAME-COORDINATION § A.2 + § G.2 (cor-confirmed 2026-06-09).
    */
   vector?: {
     /**

src/utils/collation.ts

@@ -7,12 +7,12 @@
  * and is byte-for-byte identical to Rust's `str::cmp` (`as_bytes().cmp()`). This is:
  * - **deterministic** across environments (unlike `localeCompare`, whose default-locale
  *   ordering varies by OS / Node / ICU build — unsafe for a persisted sorted index), and
- * - **cross-language consistent** with `@soulcraft/cortex`'s native column store and
+ * - **cross-language consistent** with `@soulcraft/cor`'s native column store and
  *   aggregation sort, so query results are identical with or without the native plugin.
  *
  * Use this instead of `String.localeCompare` and the `<`/`>` operators (which compare
  * UTF-16 code units and diverge from code-point order for supplementary-plane characters)
- * wherever ordering is persisted or must match the native engine. See cortex `docs/ADR-001`.
+ * wherever ordering is persisted or must match the native engine. See cor `docs/ADR-001`.
  */
 
 const utf8 = new TextEncoder()

src/utils/entityIdMapper.ts

@@ -40,7 +40,7 @@ import type { EntityIdMapperProvider } from '../plugin.js'
  * The largest entity int the JS fallback `EntityIdMapper` will allocate.
  * The metadata index's roaring bitmaps are 32-bit-keyed (`Roaring32`), so
  * allowing the JS counter past this point would silently corrupt every
- * downstream bitmap. The cortex 3.0 binary mapper supports a U64 IdSpace
+ * downstream bitmap. The cor 3.0 binary mapper supports a U64 IdSpace
  * for brains above this ceiling — see the
  * [`EntityIdSpaceExceeded`](#EntityIdSpaceExceeded) message for the
  * migration pointer.
@@ -50,8 +50,8 @@ export const U32_ENTITY_ID_MAX = 0xffff_ffff
 /**
  * Thrown by the JS fallback `EntityIdMapper` when `nextId` would exceed
  * [`U32_ENTITY_ID_MAX`](#U32_ENTITY_ID_MAX). The JS path is the
- * cortex-free fallback; once a brain has more than ~4.29 B entities,
+ * cor-free fallback; once a brain has more than ~4.29 B entities,
- * callers MUST install the cortex 3.0 `NativeBinaryEntityIdMapper` with
+ * callers MUST install the cor 3.0 `NativeBinaryEntityIdMapper` with
  * `idSpace: 'u64'` (mmap-backed extendible-hash KV; persists the full
  * u64 range losslessly).
  *
@@ -96,7 +96,7 @@ export interface EntityIdMapperData {
  * Maps entity UUIDs to integer IDs for use with Roaring Bitmaps.
  *
  * Implements {@link EntityIdMapperProvider}: the surface a registered
- * `'entityIdMapper'` provider (e.g. Cortex's native mapper) must also satisfy.
+ * `'entityIdMapper'` provider (e.g. Cor's native mapper) must also satisfy.
  */
 export class EntityIdMapper implements EntityIdMapperProvider {
   private storage: StorageAdapter
@@ -162,7 +162,7 @@ export class EntityIdMapper implements EntityIdMapperProvider {
    * The JS fallback mapper caps at [`U32_ENTITY_ID_MAX`](#U32_ENTITY_ID_MAX)
    * to match the metadata index's Roaring32 bitmap width — once `nextId`
    * would exceed that, throws {@link EntityIdSpaceExceeded} so the caller
-   * loudly migrates to cortex's binary mapper with `idSpace: 'u64'`
+   * loudly migrates to cor's binary mapper with `idSpace: 'u64'`
    * rather than silently truncating entity ids.
    */
   getOrAssign(uuid: string): number {

src/utils/metadataIndex.ts

@@ -77,7 +77,7 @@ export interface MetadataIndexConfig {
 }
 
 export interface MetadataIndexOptions {
-  entityIdMapper?: EntityIdMapper // Optional pre-configured EntityIdMapper (e.g., native from cortex)
+  entityIdMapper?: EntityIdMapper // Optional pre-configured EntityIdMapper (e.g., native from cor)
 }
 
 /**
@@ -107,7 +107,7 @@ interface FieldStats {
 /**
  * Implements {@link MetadataIndexProvider}: the metadata-index surface Brainy
  * calls on whatever the `'metadataIndex'` provider resolves to (its own
- * manager, or Cortex's native Rust engine).
+ * manager, or Cor's native Rust engine).
  */
 export class MetadataIndexManager implements MetadataIndexProvider {
   private storage: StorageAdapter
@@ -221,7 +221,7 @@ export class MetadataIndexManager implements MetadataIndexProvider {
     // Get global unified cache for coordinated memory management
     this.unifiedCache = getGlobalCache()
 
-    // Use injected EntityIdMapper (e.g., native from cortex) or create JS fallback
+    // Use injected EntityIdMapper (e.g., native from cor) or create JS fallback
     this.idMapper = options.entityIdMapper ?? new EntityIdMapper({
       storage,
       storageKey: 'brainy:entityIdMapper'
@@ -2196,7 +2196,7 @@ export class MetadataIndexManager implements MetadataIndexProvider {
       if (b.value == null) return order === 'asc' ? -1 : 1
       if (a.value === b.value) return 0
       // Numbers compare numerically; everything else by code-point (UTF-8 byte) order.
-      // This makes the JS fallback sort match cortex's native column store exactly
+      // This makes the JS fallback sort match cor's native column store exactly
       // (numeric i64/f64 vs code-point strings) and stay deterministic across
       // environments, unlike the `<` operator's UTF-16 ordering for strings.
       let comparison: number

src/utils/recallPreset.ts

@@ -7,7 +7,7 @@
  * provider (DiskANN-style) has taken over the `'vector'` provider key.
  *
  * **Public contract** — locked in handoff thread BRAINY-8.0-RENAME-COORDINATION
- * § A.2 (cortex-confirmed 2026-06-09):
+ * § A.2 (cor-confirmed 2026-06-09):
  * - `'fast'` — minimum-latency search, accepts lower recall
  * - `'balanced'` — Brainy 7.x defaults, the right pick for almost everyone
  * - `'accurate'` — maximum recall, accepts higher latency
@@ -16,7 +16,7 @@
  *
  * **Knob mapping** — the JS HNSW preset values below match what Brainy 7.x
  * shipped as defaults for `'balanced'`. Native acceleration providers (e.g.
- * cortex's DiskANN wrapper) read the same `recall` value off the index
+ * cor's DiskANN wrapper) read the same `recall` value off the index
  * config and translate it to their own internal knobs.
  */
 

src/utils/resultRanking.ts

@@ -8,7 +8,7 @@
  * This module exposes a swappable `sort:topK` seam:
  * - {@link rankIndicesByScore} returns the indices of `scores` ordered exactly as a
  *   descending stable sort would order them, then truncated to `k`.
- * - {@link setSortTopKImplementation} lets a native plugin (e.g. cortex's Rust
+ * - {@link setSortTopKImplementation} lets a native plugin (e.g. cor's Rust
  *   partial-sort / heap-select) replace the JS implementation. The native provider
  *   only has to return the same *index ordering* the JS path produces.
  *
@@ -147,7 +147,7 @@ export function reorderByIndices<T>(items: T[], order: number[]): T[] {
 }
 
 /**
- * Replace the `sort:topK` implementation at runtime (e.g. cortex's native partial sort).
+ * Replace the `sort:topK` implementation at runtime (e.g. cor's native partial sort).
  * Called by `brainy.ts` when a `sort:topK` provider is registered. Pass
  * {@link sortTopKIndicesJs} to restore the JS default.
  *

src/utils/roaring/index.ts

@@ -31,7 +31,7 @@ let _impl: typeof WasmRoaringBitmap32 = WasmRoaringBitmap32
 
 /**
  * Replace the RoaringBitmap32 implementation at runtime.
- * Called by brainy.ts when a cortex 'roaring' provider is registered.
+ * Called by brainy.ts when a cor 'roaring' provider is registered.
  */
 export function setRoaringImplementation(impl: typeof WasmRoaringBitmap32) {
   _impl = impl

src/utils/unifiedCache.ts

@@ -63,7 +63,7 @@ export interface UnifiedCacheConfig {
  *
  * Implements {@link CacheProvider}: the surface Brainy calls on whatever cache
  * is installed as the global cache (its own instance, or a registered
- * `'cache'` provider such as Cortex's native eviction engine).
+ * `'cache'` provider such as Cor's native eviction engine).
  */
 export class UnifiedCache implements CacheProvider {
   private cache = new Map<string, CacheItem>()
@@ -444,7 +444,7 @@ export class UnifiedCache implements CacheProvider {
   /**
    * Dynamically resize the cache maximum. If the new size is smaller than
    * the current usage, evicts lowest-value items until the cache fits within
-   * the new budget. Used by Cortex's ResourceManager to rebalance cache vs
+   * the new budget. Used by Cor's ResourceManager to rebalance cache vs
    * instance memory as brainy instances are created and evicted.
    *
    * @param newMaxSize - New maximum cache size in bytes