Here's the gap. If I want to see what's actually sitting inside a MongoDB collection in KaryoSpace, right now, today, I open a third-party tool. Compass, or a shell, or a one-off script. There is no way to look at my own data from inside my own app. I built an enterprise platform that stores email, chat, knowledge documents, incidents, and query history, and the only person who can casually glance at a document is whoever has database credentials and a separate piece of software open.
That's an odd thing to have let slide this long, and it's not the only gap. There's also nowhere that shows how the collections relate to each other. No diagram of what points at what. And the moment a user actually asks KaryoSpace a question, everything that happens between them hitting enter and a response appearing is invisible unless I go read logs by hand.
Partly because AIO already gave me a version of this and it felt like enough for a while. AIO, the observability layer I wrote about separately, tracks every AI interaction at the level of an outcome: did a guardrail intercept it, did retrieval fire, which collections contributed, was the answer served from cache. It's genuinely useful, and it's saved me more than once.
But AIO answers "what happened." It doesn't answer "what does the data actually look like" or "how do these fifteen-odd collections fit together." Those are different questions, and I've been answering them by opening Compass and squinting, which works fine for me and works for nobody else who might ever touch this codebase.
The first piece is the plainest one: a screen inside KaryoSpace, admin-gated, where you pick a collection, browse real documents, and see the actual shape of the data. Not a spec someone wrote eight months ago and never updated. The document as MongoDB holds it right now, this query.
This sounds almost too simple to write a blog post about, and that's exactly why it's been sitting undone. It's not a hard feature. It's just never been the most urgent one.
The second piece is harder because MongoDB doesn't actually enforce a schema, which means there's no schema to introspect. The relationships are real, an email_message references a mailbox which references a user, a user_queries entry references an org, a knowledge atom references the documents it was distilled from, but they only exist as ObjectID fields scattered across Go structs, held together by convention rather than a foreign key constraint.
So an entity-relationship diagram here can't come from introspecting the database the way you would with Postgres. It has to come from reading the Go structs and their bson tags and building the map from that, either by hand or by walking the struct definitions with reflection. Hand-maintained diagrams rot the moment I add a field and forget to update a picture nobody's looking at. I'd rather generate it from the structs directly, even if that means the first version only catches the relationships I've tagged explicitly.
The browser and the diagram are useful. This is the part I actually care about.
When a user asks KaryoSpace something, a specific sequence runs. A guardrail check happens first. Then the classifier decides whether this is a statement, a plain question, or something that should trigger retrieval at all. If it's a RAG query, the retriever runs a MongoDB $text search across the relevant collections for that org, pulls a candidate pool three times the size it actually needs, capped at 60, and re-ranks those candidates by cosine similarity against the 768-dimensional nomic-embed-text vectors already stored alongside each document. The assembler then builds the final prompt: numbered, source-labelled context blocks under a hard 3,000-character cap, with the current date and the user's identity injected so the model doesn't have to guess at either. That prompt goes to whichever LLM provider is configured, Groq or Gemini or a local Ollama model, and the response comes back with source badges showing which collections it actually drew from.
I know all of this because I wrote it. Nobody else does, and even I have to reconstruct it from memory or from the source when I'm debugging something three months later.
What I want is a screen where you type a question, or pick a real one from the query history, and watch that sequence animate stage by stage: the guardrail check lighting up green or red, the classifier's decision, the candidate documents pulled by text search, the re-ranking scores changing the order, the assembled prompt with its source labels visible, and finally the model call and the response, each stage showing the actual data at that step rather than a description of it.
Most of the instrumentation for this already exists. AIO's storeUserQuery() chokepoint already captures a trace ID, the contributing source collections, and the raw retrieved chunks for every query, regardless of outcome. What's missing isn't new logging. It's a GUI that walks through the same trace stage by stage instead of only showing the final outcome.
KaryoSpace holds real email and chat content for real organisations. A document browser that shows raw documents, even gated to admins, is a bigger surface area than a query-outcome dashboard. I'd want field-level redaction or a strict non-production data mode before this touches anything that isn't seed data, and I haven't fully worked out where that line sits yet.
There's also a performance question I haven't answered. Instrumenting a live trace in enough detail to animate it usefully means capturing more at each pipeline stage than AIO does today. I need to make sure that capture doesn't sit on the actual query path and add latency to something that's already a chain of a text search, an embedding comparison, and an LLM call.
Not the document browser, and not the diagram, even though those are simpler. I'd start with the query trace, scoped to my own admin view and to seed or non-production data, because that's the part with the least PII risk and the most value. If watching a query animate through the pipeline turns out to be as useful for debugging as I expect, the browser and the diagram become the supporting cast rather than the main feature.
If you've built something like this for your own RAG pipeline, or you can see a reason the redaction problem is harder than I think, I'd like to hear it.
This is a Thought, an idea in progress rather than a finished system. The engineering behind KaryoSpace is at karyospace.com/blog#engineering
Do share your thoughts with me on this blog post: sumanakkisetty@gmail.com
Thanks for reaching out. We'll get back to you shortly.