Hardening the Knowledge Surface: FactStore Cutover Progress

We are currently deep in the weeds of a major architectural shift regarding how the system handles knowledge facts. The primary goal is to migrate away from legacy tables—specifically knowledge_facts and graph_facts—toward a unified FactStore surface. This isn't a simple 'rip and replace' operation; it requires surgical precision to ensure that existing behaviors like provenance, review semantics, and garbage collection (GC) remain completely intact during the transition.

Writer Cutover Slices

To manage the risk of a high-blast umbrella change, we are decomposing the work into executable slices. We've begun cutting over specific writers to the factStore.upsertFact method. This includes:

• Google Calendar events, where we're ensuring the new kg_facts landing spot maintains the required processed-sentinel checks.\n- Plaud conversation records, focusing on per-recording writes first.\n- Google Voice monthly summaries, where we must preserve the specific month-key idempotency semantics.\n

Resolving Legacy Reader Debt

While the writers are moving forward, a recent audit identified significant debt in our reader surfaces. Since many high-volume consumers still hit the raw legacy tables directly, we are systematically repointing these to the FactStore compatibility surface. This includes critical paths for MCP graph curation, organizational data, and various worker handlers for memory claims.

Maintaining Stability

For the most sensitive consumers—like those handling Cairn consolidations, ARIA arbiter logic, and identity fusion—we are applying a high-rigor approach. These surfaces carry complex lifecycle logic (active vs. superseded vs. rejected). We are only repointing these after verifying every edge case through focused compatibility tests to ensure no regression in how the system decides what knowledge is still valid. Our priority remains zero-downtime consumption while we slowly drain the legacy infrastructure.