> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prodexlabs.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Knowledge Base
> Dexter's per-factory knowledge base: the index, your standing rules, and the memory areas that carry your operation's context across conversations.
## Overview
Memories are how [Dexter](/product/ai-assistant) remembers your operation across conversations — what your factory does, how it actually runs, what you've told Dexter to always do (or never do), and what's been built in the platform so far. Without them, every conversation would start from zero.
Dexter's memory lives in a **knowledge base** scoped to the active [Factory](/getting-started/key-concepts). The knowledge base belongs to your factory — Dexter reads and writes it as you work, and you can read and steer it from the **Knowledge Base** tab in the top navigation. Sharing a factory doesn't put two people into one shared knowledge base: [sharing](/product/factory-management) hands the other person their own copy of the factory, and from then on each of you reads and edits a separate knowledge base — a change on one side doesn't automatically sync to the other. You're not sealed off forever, though: from a shared factory you can **Publish Update** to push a new version — knowledge base included — to your collaborators, and each of them chooses whether to apply it. A second layer — [organization memories](/product/dexter/organization-memories) — is curated by your organization's admins and shared across every factory in your organization.
## Inside the Knowledge Base
The knowledge base is a small, cultivated corpus, not a dumping ground. Two entries are always loaded — the index and your rules — and beneath them sit three areas:
| What | Contains |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **The index** — the catalog | A one-page overview of the operation, the user, what's currently being worked on, and a table of contents pointing at everything else. Dexter reads it at the start of every conversation, and the Knowledge Base home page renders it as the **Start here** card. |
| **Your rules** | How you want Dexter to work: preferred units, formatting conventions, things to always do, things to never do, sign-off requirements. Binding, and read at the start of every conversation. See [Rules and preferences](#rules-and-preferences). |
| **Operation** | How the factory actually runs — process flow, capacity, bottlenecks, constraints, schedules, roles, vocabulary, conversion factors, KPIs, layout, known quirks — in your terms, not a generic template. Flat by default; grouped into subsections only as it grows. |
| **Data sources** | One entry per uploaded data source: schema, what codes and symbols mean, how to interpret the file, common pitfalls, and how it maps back to the **Operation** area. |
| **Platform** | Living records of what you've built in ProDex — one per simulation model, planning model, or BOM: how it was built, what's in it, what's been verified, and its key invariants. A single artifact may span several entries when there's a lot to capture. |
Dexter also keeps a **journal** — a day-by-day log of what happened across sessions — and an **environment** area holding notes about its own tooling and how it works inside ProDex. These exist for Dexter's own continuity and are not shown in the Knowledge Base views — you'll only ever see the index, your rules, and the three areas above. [Organization memories](/product/dexter/organization-memories) are likewise not browsable from the factory.
A well-cultivated **Operation** area typically settles around 20–30 focused entries. Quality beats volume: Dexter navigates memory through the index, so a tight catalog of current, factual entries outperforms an archive of stale notes.
## How Memories Get Written
Dexter cultivates the knowledge base **automatically, in the background**. During quiet moments between turns, and before a long conversation compacts, it reviews what it has learned and folds the durable parts into memory — so a hard-won detail about your operation isn't lost when a conversation ends or ages out.
You can also **ask Dexter to update memory explicitly** at any time, which is the surest way to capture something the moment it's decided:
* *"Update the knowledge base with what we figured out today."*
* *"Add a rule that we always report tonnage in short tons."*
* *"Prune anything about the old paint line — we decommissioned it."*
* *"Forget the entry about the second-shift changeover — it's out of date."*
However a change is triggered, when Dexter curates it scans the index and the relevant area first, updates entries in place instead of duplicating them, removes outdated content rather than annotating it, and asks before overwriting anything that contradicts what's already there. When it adds or removes entries, it updates the index so the catalog stays honest.
You don't have to wait for the background pass. End a working session with an explicit *"update the knowledge base with what we settled today"* whenever something you'll rely on later has just been decided. If Dexter is ever missing context you'd expect it to have, that's the signal to ask for a pass.
## Viewing and Editing Memories
Open the **Knowledge Base** tab in the top navigation. It offers three views:
* **Home** — the landing page: the **Start here** card rendering the index with its table of contents, browse cards for the **Operation**, **Data sources**, and **Platform** areas, a **Recently updated** list, and a search box that searches the whole knowledge base. You can also open that search from anywhere with **Ctrl+K** (**⌘K** on Mac).
* **Files** — the full file tree. Open any entry to read its rendered Markdown, and download any entry from its row. You browse and read here; to change what's stored — correct an entry, add a new one, prune something stale — ask Dexter (*"update the entry on the extrusion line,"* *"add a note that we always report tonnage in short tons"*) and it writes the change for you.
* **Graph** — the knowledge graph: every memory as a node, with edges for the links between files. Use it to see how areas connect and to spot orphaned or missing entries (a grayed-out node is a file that's linked to but hasn't been written yet).
You can also just ask Dexter: *"What do you know about the extrusion line?"* or *"Show me the rules you're operating under."* Dexter reads the relevant files and tells you what's there.
**Prune periodically.** Every so often, ask Dexter to clear out stale entries — *"prune anything about the old paint line"* or *"forget the second-shift changeover entry"* — and it deletes them and updates the index. A tight, current catalog keeps every future conversation sharper.
## How Dexter Uses Memory in a Conversation
1. At the start of every conversation, Dexter loads the index and your rules — the catalog and your standing rules are always in context.
2. As the task develops, Dexter pulls in specific entries from the **Operation**, **Data sources**, or **Platform** areas when the index suggests they're relevant.
3. [Organization memories](/product/dexter/organization-memories) are read the same way, as shared background context.
4. Dexter references what it read, so you can trace where an assumption came from.
Knowledge taught in one conversation carries into all future conversations in the same factory — but only after it's been written to the knowledge base. If a decision only lives in chat history, it isn't memory yet.
## Rules and preferences
**Rules** are your standing instructions to Dexter — the things you want it to always do, never do, or default to in this factory. They live in the knowledge base as your **rules** entry, one of the two entries Dexter loads at the start of every conversation, and Dexter applies them to every response. Use them for the small, persistent preferences that would otherwise cost you a correction every time: units, formats, terminology, review thresholds, tools you always or never want used, people to loop in.
If you find yourself correcting Dexter the same way in more than one conversation, that's a rule. If you're teaching Dexter a fact about the operation, that belongs in one of the memory areas above.
### Rules vs. facts
Both persist, but they play different roles. A **rule** is an instruction — *how* Dexter should work ("always report throughput in units per shift, not per hour"). A **memory** is a fact — *what* Dexter knows about your operation ("the paint line runs three shifts Mon–Fri, two on Saturday"). Rules are loaded and applied on every response, so the list stays short; the memory areas are pulled in as relevant and grow over time. Don't put operational data ("the paint line has 4 booths") into rules — it belongs in the memory areas, where Dexter uses it in context rather than repeating it in every reply.
### Managing your rules
The usual way to set a rule is to tell Dexter in the middle of other work: *"From now on, always report throughput per shift, not per hour,"* or *"Stop asking me to confirm before running short simulations."* To drop one, say so just as plainly — *"Forget the rule about ISO dates."* Dexter updates the rules entry and confirms what changed, and only touches it when you explicitly ask — it won't quietly mine rules out of ordinary conversation.
You can open the rules entry under **Knowledge Base** to read exactly what Dexter is operating under at any time. As with the rest of the knowledge base, that view is read-only — you change rules by asking Dexter, not by editing the file in the page.
A rule you add through Dexter is saved to the rules entry right away, but each conversation works from the copy of your rules it loaded when it started (and reloads when the conversation compacts). So a newly written rule is reliably picked up by your **next** conversation — and can take hold mid-conversation when the context is refreshed — rather than being guaranteed to bind on the very next turn. To apply something in the current chat immediately, restate it as a one-time instruction.
### Scope
* **Per-factory.** Rules apply to a single [Factory](/product/factory-management). Different factories keep separate rules — Dexter doesn't carry them from one factory into another.
* **Yours, in your copy.** Your rules live in your factory's knowledge base. If you [share the factory](/product/factory-management), the other person receives their own copy — including a snapshot of your rules at that moment — and from then on each of you edits your own rules independently. There's no shared list two people co-edit, and no live sync between copies.
* **Not org-wide.** Rules don't propagate across the organization. Organization-shared instructions live in [organization memories](/product/dexter/organization-memories), curated by admins; a factory rule you set overrides a generic organization memory when the two conflict, and Dexter surfaces the conflict rather than silently choosing.
### When rules apply
Rules apply to **every response Dexter generates** in the factory — every question it asks, every artifact it authors, every review brief, every report — and take precedence over Dexter's own defaults. An instruction given inside a single conversation (*"use metric units for the rest of this chat"*) is a one-time instruction, not a rule; to make it stick, ask Dexter to add it as a rule.
### Examples
Rules users actually find worth setting:
* **Units and formatting.** "Always report throughput in units per shift." "Round currency to whole dollars in tables." "Use ISO dates (YYYY-MM-DD) in reports."
* **Vocabulary.** "Call the paint line the 'finish line' — that's what the floor uses." "Our SKUs are always prefixed with the plant code; don't strip it."
* **Defaults.** "Default simulation run length is two weeks." "Assume five-day work weeks unless I say otherwise."
* **Review thresholds.** "Ask before making changes to the planning model." "Always show me a brief before generating a PDF report."
* **Communication style.** "Keep responses short unless I ask for detail." "Skip the executive summary — I want the numbers first."
* **What to skip.** "Don't propose reports at the end of analyses — I'll ask when I want one." "Don't auto-navigate; I prefer to click through myself."
### Limits and caveats
* **Keep the list tight.** Every rule is loaded into Dexter's context at the start of a conversation, so a sprawling list dilutes the important ones. Prune rather than annotate — if a rule is stale, ask Dexter to remove it.
* **Rules don't retroactively fix past work.** A new rule applies going forward; existing artifacts aren't rewritten unless you ask.
* **Conflicting rules cause noise.** If two rules pull opposite ways ("always be concise" + "always include full derivation"), Dexter flags the conflict — resolve it by revising the list.
* **Your rules are your own.** Because sharing a factory hands over a separate copy, a rule you set only affects your knowledge base — it doesn't reach a teammate's copy, and theirs don't reach yours.