Activation

Activation is Cortex’s answer to the question: “out of all the records that match this query, which ones are actually relevant right now?”

It is not retrieval. It is ranking. FTS plus metadata gets you the candidate set; activation determines the order.

The mechanic

Every recall has a side effect: it inserts an access_event row for each returned record into a dedicated table:

record_id     | accessed_at         | source
--------------+---------------------+--------
rec-...       | 2026-04-25T09:14:22 | recall
rec-...       | 2026-04-25T11:01:08 | session_start

The source field tags how the access happened — explicit recall, session start injection, status pull. Different sources can be weighted differently.

A SQL VIEW aggregates the table:

CREATE VIEW v_activation AS
  SELECT record_id,
         COUNT(*) AS access_count,
         MAX(accessed_at) AS last_access
  FROM access_events
  GROUP BY record_id;

The recall ranker joins against this view and computes an activation score combining count and recency:

activation = (access_count * weight) * exp(-decay * days_since_last_access)

The exponential decay means a record that was accessed frequently months ago does not dominate over a record that has been accessed once this week.

Why this and not embeddings

Embedding-based retrieval is a different solution to a different problem. It is good at semantic similarity — finding records that talk about the same thing in different words.

The problem activation solves is different. The candidate set has already been filtered by FTS or by scope. The question is no longer “which records are about this topic?” but “which of these matter to this user, right now?”

Embeddings do not answer that question. Usage history does.

The two could be combined — embeddings for candidate selection, activation for ranking. Cortex does not currently do that; FTS plus activation is enough for most queries, and adding embeddings adds an ingestion cost (running the embedding model on every record) that is hard to justify against the marginal recall improvement.

Configuration

Activation is configurable in ~/.cortex/config.yaml:

retrieval:
  activation:
    enabled: true
    decay: 0.5      # exponential decay rate per day
    weight: 0.3     # contribution to overall ranking

Disabling activation falls back to pure FTS-plus-recency ranking. The records still rank, just without the usage signal.

Cost

The cost of activation is one insert per returned record per recall, plus one indexed lookup against the view at ranking time. Both are cheap; the view aggregation is fast on a few hundred thousand access events because SQLite indexes the underlying table.

For very long-lived stores, the access events table can be periodically truncated to a recent window. The view rebuilds in milliseconds.

What activation is not

• It is not a substitute for explicit scope. A record outside the requested scope is not in the candidate set; activation does not save it.
• It is not a popularity contest. Records used by the system itself (e.g. injected at session start) accumulate access events the same way as user-driven accesses. The source field lets the ranker discount these if needed; in the default configuration they count, because system injection is itself a useful signal.
• It is not memorisation. Activation is computed at query time from the events table. There is no learned model. Anyone can read the formula and reason about why a record ranked where it did.