usemoos

Most retrieval systems fetch first and filter the results afterward, which means an unauthorized document sits in the context window for a moment before anything decides to hide it. usemoos checks what a user is actually permitted to see before the retrieval query runs at all, so a document that user has no access to never enters the context window in the first place. The permission check is the first thing that happens, not a filter bolted onto the end.

Isolation between customer organizations is enforced at the query layer itself, not in the UI and not in application logic sitting on top of a shared query. That distinction matters because a UI level restriction can be worked around by anything that talks to the data layer directly. A query layer restriction can't be.

QA caught the system triggering a full document retrieval on a plain greeting. Nothing about "hey" or "good morning" needed a knowledge base search, but the system ran one anyway, which slowed the reply down and returned citations that had nothing to do with what was actually asked. An intent classification step now runs ahead of retrieval, so small talk gets answered directly and a search only fires when the turn is an actual question.

The visual system came before any screen did: a single source of truth token system, a component and primitive library, and a set of responsive rules, all built first and then implemented against consistently across the marketing site, the authenticated workspace, settings, and onboarding. Past that baseline, the polish passes are the kind that separate a working prototype from a product employees actually want to use: live sync progress indicators so a connection in progress doesn't look frozen, streaming responses with citations rendered inline as the answer arrives, and navigation refined enough that moving between a workspace and a specific document doesn't lose your place.

An offline evaluation pipeline scores every retrieval and generation change against a golden dataset using an LLM as judge, measuring faithfulness, answer relevancy, context recall, and context precision, so a change to the pipeline gets measured, not eyeballed. That harness caught its own bug once: it was scoring answers against a smaller context window than production actually used, which meant the scores looked fine while not describing what customers were actually getting. Realigning the two made the eval numbers trustworthy again.

The same harness is what justified real architecture changes rather than gut calls: an embedding model upgrade, a reranker upgrade, and two query enrichment techniques, hypothetical document generation and step back abstraction, run in parallel with retrieval at no added latency cost. Contextual chunking, prepending a document's section hierarchy before embedding, came out of the same process.

The harness also caught a regression that a metric alone wouldn't have explained: open ended discovery questions were getting worse answers, and the cause turned out to be the generation model simply choosing not to call the search tool on that kind of question. The fix replaced tool triggered retrieval with a recall first router plus a corrective RAG pass, closing a failure mode specific to knowledge search products, where the model's own judgment about when to search is itself something that can quietly go wrong.

Container deployment, the job queue, and the database all got migrated to managed infrastructure solo, without the product going down during any of it. A CI pipeline gates every merge on lint, type checking, and integration tests, with job level timeouts added specifically so a hang shows up as a failed check instead of a silently stalled pipeline. Production incidents, a queue client crash loop from a clustering mode mismatch, a stale auth token bug surfacing right after OAuth, a container build accidentally pulling in another service's dependencies, each got root caused and closed with a regression guard, not just patched and left to recur.