Knowledge Architecture
1. Why “knowledge architecture” deserves its own page
In Prodia, the knowledge loop explains how experience is accumulated, reviewed, reused, and improved over time. Knowledge architecture explains how that knowledge is actually stored, indexed, retrieved, injected into context, and governed at runtime.
The two ideas are related, but not identical:
- knowledge loop focuses more on why knowledge matters and what value it creates
- knowledge architecture focuses more on how the knowledge system really operates
2. Why it is not just a vector database
If Prodia’s knowledge system is reduced to “upload documents and run embeddings”, several important realities are lost:
- original files are archived separately instead of being reduced to chunks only
- archived source files and indexed knowledge entries are two different layers
- retrieval is not pure vector similarity, but hybrid recall plus intent-aware expansion
- retrieved knowledge is not always injected directly into the model
- auto-extracted structured knowledge can still enter a draft and review path
So in Prodia, the knowledge system is closer to a governed runtime subsystem than to a single RAG component.
3. The five layers of the knowledge architecture
From a product perspective, the knowledge architecture can be understood through five layers:
| Layer | Purpose |
|---|---|
| source archive layer | preserves original files, sources, and downloadable evidence |
| knowledge catalog layer | stores chunks, structured entries, keywords, and index state |
| retrieval orchestration layer | combines vector recall, keyword recall, reranking, and source expansion |
| context injection layer | decides how knowledge enters the current turn |
| governance and evolution layer | handles drafts, review, rebuilds, structured extraction, and metadata sync |
That means the knowledge system is not just about storage. It is a running chain.
4. What a typical knowledge path looks like
Typical knowledge sources include:
- product documents, manuals, SOPs, and reports
- glossary items, rules, and diagnosis mappings
- historical cases, review outputs, and expert notes
- tool metadata and system capability descriptions
5. Why source archive and knowledge catalog are separate
This separation matters in industrial scenarios because it solves three practical problems:
1. Traceability
When the system cites knowledge, it can still return to the original file instead of leaving only a detached chunk.
2. Rebuildability
If chunking, indexing, or structured extraction logic changes, the system can rebuild from archived source material.
3. Governability
Original files, catalog entries, draft knowledge, and published knowledge can have different lifecycles instead of being mixed together.
6. Why retrieval is not “search and dump into the model”
After retrieval, Prodia still needs to decide:
- whether the result is truly useful for the current question
- whether it should enter as a tool result or as contextual support
- whether it acts as explanation evidence, diagnostic know-how, or glossary support
- whether the current context budget is worth spending on it
That is why the knowledge system is tightly connected to Context Engineering. The knowledge layer answers “can we find it?” while context engineering answers “should the model actually see it now?”
7. How knowledge architecture relates to the knowledge loop and memory
| Mechanism | Main concern |
|---|---|
| Knowledge Loop | how experience is accumulated, reused, and improved over time |
| Knowledge Architecture | how knowledge is archived, indexed, retrieved, injected, and governed |
| Memory Mechanism | how conversational continuity and user-specific carry-over are preserved |
A practical shorthand is:
- knowledge loop explains why experience should become reusable
- knowledge architecture explains how that knowledge runs inside the system
- memory explains how continuity is preserved across turns
8. What this means for the product
Knowledge architecture makes Prodia stronger in four direct ways:
- more traceable outputs because results can point back to source material
- more governable evolution because drafts, review, rebuild, and structured extraction are supported
- more reusable explanation because knowledge can be invoked systematically instead of staying as static documentation
- more extensible platform behavior because document knowledge, structured knowledge, and tool knowledge can enter one architecture
If you want to start from the value perspective, read Knowledge Loop. If you want to understand how retrieved knowledge enters the current turn, continue with Context Engineering.