Cortex: Context as a Service

Because they answer different questions and no single engine answers all three well. Postgres answers "what is claimed, by whom, at what scope" - relational, transactional, with a query planner that has been tuned for decades. Qdrant answers "what is this like" over a few hundred dimensions. FalkorDB answers "what connects to what" in a traversal that would be a recursive CTE nightmare in SQL.

The alternative was pgvector plus a recursive CTE, keeping everything in one engine. That is genuinely simpler, and for a smaller store it would be the right answer. It was rejected because the traversal is not incidental here - spreading activation is the whole retrieval model, and a graph engine that does it natively beats a CTE that emulates it.

The cost is consistency across three engines. That cost is contained by making two of them derived: Postgres is truth, the other two are projections, and a reconcile sweep can rebuild either.

The cascade has three steps: semantic search in Qdrant, graph expansion in FalkorDB, then scoring in Postgres. The first two were buildable. The third needed a ranking function, and the one on paper at the time was six hand-weighted signals that nobody had fitted against anything.

Shipping it would have produced a working pipeline returning confidently-ranked results with no evidence the ranking was better than recency. That is worse than not shipping it, because it looks finished. The honest move was to write the cascade down, mark the scoring step as unbuilt, and go find out what the function should actually be.

It became ACT-R activation, and fitting it properly took most of Milestone 2. The first fit found a constant that had silently disabled the entire decay term. That error would have shipped invisibly in M1.

A Temporal workflow replays its event history to rebuild state. Keep the conversation in a workflow field and every turn makes every future replay more expensive - and the history has a hard size limit you eventually hit. The obvious fix, ContinueAsNew, only helps if there is little state to carry across the boundary.

So the workflow holds no history at all. It holds a queue of prompt signals and reloads context from Postgres each turn. ContinueAsNew after 100 turns carries nothing. The database was already the durable record; duplicating it into workflow state bought nothing and cost replay.

This design had one real bug: prompts still sitting in the queue at ContinueAsNew were silently dropped. Found and fixed in M2 - the queue is drained before the boundary.

Input, output, and collating - the last being the model's reasoning tokens, which are a separate concern from its answer and belong on their own channel. A consumer that wants only the answer never reads the thinking.

"Redis-first" means the durable stream is written before the real-time notification goes out, not after. Push to SignalR first and a client that reconnects two seconds later has no way to recover the tokens it missed - the notification was the only copy. Writing the stream first makes reconnection a read.

The streams get a 24-hour TTL and an explicit end-of-stream sentinel. Without the sentinel a consumer cannot distinguish "generation finished" from "generation stalled", and that ambiguity ends up rendered as a spinner that never stops.

The tests run against live services through Aspire - real Postgres, real Redis, real Temporal, real Qdrant. Eleven test projects meant eleven Aspire boots, and the boot dominated the run. The suite was slow enough that it stopped being run.

One project with a shared PlatformFixture boots the platform once: 136 tests in about 30 seconds. The tradeoff is that test classes now share a platform and must not assume an empty database - every test scopes its own data. That discipline is worth a suite people actually run.

Integration tests run against live services, not mocks. If the test passes, the code works in production.

The intuitive model is that a superseded entry is dead - you replaced it, stop walking to it. That is wrong for a memory store. The superseded version is often the thing someone remembers, and it is the only route from an old mental model to the current one.

Traversal follows supersession in both directions: a query that lands on the old decision reaches the correction, and a query about the correction can see what it replaced. Nothing is removed from the graph - it is re-pointed.

This became load-bearing later. The context store's First Law says no claim may be destroyed, only superseded, and the superseded claim stays queryable forever. The graph was already built that way before the law was written down.