Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 09 · LESSON 9.1

Choose the right place for knowledge

Put each kind of knowledge in the store that matches its purpose.

Lesson 48 of 86 · FabrCore 2.0

Overview

A request record belongs in typed business storage. A conversation belongs in chat history. A reusable instruction package belongs in runtime skills. Memory stores durable scoped facts/procedures, while GraphRAG indexes document evidence and relationships for retrieval.

Choose by how the information will be used

The canonical status of SR-1042 belongs in the request system or typed business storage. Messages about that request belong in conversation history. A reusable review procedure can be a versioned runtime skill. A confirmed user preference can be scoped Memory. Policy documents that must be cited are good candidates for GraphRAG evidence retrieval. These stores are complementary rather than competing names for one feature.

Match the information to its source
Component / choice What it owns What it does not do
Request status Authoritative business system / typed record Infer the current status from a past chat answer
Conversation Thread history and session selection Automatically share facts across every thread
Review procedure Versioned runtime skill package Become executable application code
Confirmed preference Principal-scoped Memory Become a global policy for other users
Policy evidence Scoped GraphRAG index with source references Guarantee the model interpreted the policy correctly

Ownership and freshness matter more than convenience

A model's generated guess should not silently become an authoritative business record. Likewise, indexing a policy document does not keep it current when the source changes. Decide which component may write a fact, who may retrieve it, and how corrections or deletions propagate. Keep the user's trusted scope outside model-selected inputs.

Place each kind of information

  1. Classify SR-1042's record, the user's preference, a policy-review procedure and the policy PDF separately.
  2. Choose a stable trusted scope for Memory/GraphRAG and document intentional sharing. Scope strings do not authorize access on their own.
  3. Keep unverified bulk tool output in history until trusted application logic or a controlled extraction process identifies durable knowledge.

Classify the Operations Desk inputs

  1. Make a list containing request status, this conversation, a review procedure, a confirmed notification preference and a policy PDF. Assign each to the store described above and name its authoritative owner.
  2. For each item, specify its permitted readers and how an update is recognized. A user's preference must not become a global policy merely because it was easy to save.
  3. Choose one item to add next. If the requirement is just to remember the current thread, verify module 4's history setup before introducing Memory.

The result is a data placement decision. It prevents using semantic retrieval as a substitute for an authoritative record or ordinary conversation persistence.

If the result is different

Do not save every intermediate thought as Memory or use embeddings as a replacement for authoritative transaction storage.

Go deeper

Explore the related documentation.