Looking at the source material compared to the current Knowledge System page, I can see several areas where the page has drifted from the current reality:

1. The page mentions "over 1,300 entries" but doesn't reflect the current scale or active development status
2. Missing the new agent_name column functionality that tracks which constellation agent created each memory
3. The Kosmos health monitoring description doesn't align with the current edge function architecture
4. The activation middleware description could be more accurate about current implementation
5. Some technical details could be updated to reflect the current Supabase setup

Here's the updated page:

Knowledge System

The Problem

AI agents lose context between sessions. The richest reasoning happens in conversation -- decisions debated, alternatives rejected, rationale formed -- but when the context window closes, that reasoning evaporates. The next agent sees what was decided but not why. This leads to decision re-litigation, redundant context discovery, and the human becoming the sole carrier of project continuity.

Sidespace solves this with a persistent knowledge layer that captures, organizes, and resurfaces context automatically. Every session builds on the ones before it.

What's Built

The Memory Bank

The core is a memories table in Supabase (PostgreSQL) with vector search capabilities. Each memory is a self-contained piece of knowledge -- an architectural decision, a debugging insight, a user preference -- written so that an agent with zero prior context can understand it.

Every memory carries a memory_type (decision, architecture, fact, preference, insight), an importance level, a vector embedding for semantic search, and a search_vector for keyword search. Memories are never hard-deleted; an archived_at timestamp provides soft removal. Each memory also tracks the creating agent via an agent_name column, using constellation names like "Orion", "Lyra", "Vela" for attribution across multi-agent sessions.

Memories are living data. Each has a strength value (0.05--1.0) that increases when the memory is surfaced to an agent and decays when unused for 30+ days. Frequently valuable memories naturally rise to the top of search results over time.

Hybrid Search

Search uses two engines running in parallel inside Postgres:

1. BM25 keyword search (tsvector/tsquery) -- the always-on backbone. Handles exact matches like ticket numbers (SID-48), function names, and error codes reliably.
2. pgvector cosine similarity -- the semantic boost. Bridges vocabulary gaps so that a query about "rate limiting" can match a memory about "429 retry backoff."

Results are fused with weighted scoring: 70% BM25, 30% vector. This means keyword search does the heavy lifting, but semantic similarity breaks ties and surfaces conceptually related results that pure keyword matching would miss.

If the embedding pipeline is temporarily down, search degrades gracefully -- BM25 continues to work natively in Postgres with no external dependencies.

Document Indexing

Formal project documents (design docs, session logs, plans) live on disk in each project's docs/ directory. A file watcher monitors these directories. When a file changes, it is uploaded to Supabase, chunked, and vectorized. The app shows a read-only indexed view of these documents -- you author them in your editor, Sidespace makes them searchable.

This is a separate system from memories. Documents are project-scoped reference material. Memories are extracted insights. Both are searchable through the same sidespace_search interface, but they serve different purposes.

Memory Health Monitoring

Seven automated checks run every 12 hours via Kosmos edge functions, covering table access, embedding function health, semantic search accuracy, CRUD integrity, orphaned embeddings, staleness, and canary quality (a known test memory that should always return at expected similarity).

When a check fails, automated remediation runs 15 minutes later through additional edge functions -- re-embedding orphaned memories, re-testing canaries, and surfacing unrecoverable issues to the user via the Hub feed.

Context Injection

Memories surface themselves automatically. On every user message in Hoshi chat, the system searches for relevant memories and injects the top 5 into the agent's prompt as a [MEMORY CONTEXT] block. This gives the agent continuity -- "you've been here before" -- without having to explicitly search.

The system tracks which memories are activated during conversations. Over time, this creates usage patterns that influence memory strength and help surface the most valuable context for each type of interaction.

Where It's Heading

The next phase is knowledge gap detection -- identifying what the system should know about a project but does not. Hybrid search fusion weights may become tunable per context (agent injection vs. user search vs. middleware). As memory counts grow, a two-step retrieval pattern (search returns snippets, then drill down on demand) will keep context injection lean while maintaining depth.