Knowledge Base

​

Overview

Memories are how Dexter 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. The knowledge base belongs to your factory — Dexter reads and writes it as you work, and you can read it on the Knowledge Base page in the left navigation. Sharing a factory doesn’t put two people into one shared knowledge base: sharing 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 — 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. Dexter always loads your complete rules and a short orientation from the index. The complete index and its source entries remain available when the task needs them. Beneath them sit three areas: 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 on the Knowledge Base page — you’ll only ever see the index, your rules, and the three areas above. Organization memories are likewise not browsable from the factory.

​

How Memories Get Written

Dexter cultivates the knowledge base automatically, in the background. When you step away from a conversation, and periodically as a long conversation grows (including just before it compacts), it reviews what was established and folds the durable parts into memory — facts about the operation, how to read your data sources, what was built, and preferences you stated — so a hard-won detail 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.

​

Viewing and Editing Memories

Open Knowledge Base in the left navigation, just below Chat. A dot appears next to it when Dexter has updated the knowledge base since you last looked. It’s a single page:

• Search — the Search the knowledge base… box searches every entry. You can also search the knowledge base from anywhere with Ctrl+K (⌘K on Mac).
• Start here — a card for the index (Table of contents), showing how many files the knowledge base holds and when the index was last updated. Click it to read the full catalog.
• Recently updated — every entry, most recently changed first.
• Connections — a graph with every entry as a node and lines for the links between them. Click a node to open that entry. A grayed-out node is an entry that another entry links to but that hasn’t been written yet.

Click any entry to read it as formatted text. On wider screens, a small Connections graph beside it shows the entries it links to and from. The Knowledge Base page is read-only. 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. Your own preferences are the one thing you edit directly, in the Preferences dialog — see Managing your rules. 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.

​

How Dexter Uses Memory in a Conversation

1. At the start of every conversation, Dexter loads a short orientation from the index and your complete rules.
2. As the task develops, Dexter reads the complete index or searches the knowledge base, then pulls in specific entries from the Operation, Data sources, or Platform areas.
3. A catalog of organization memories identifies shared guidance and assets for Dexter to open when relevant.
4. Dexter references what it read, so you can trace where an assumption came from.

​

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. The complete rules entry is loaded at the start of every conversation, and Dexter applies it to every response. Use rules 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.

​

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 rules entry has two parts: preferences you write yourself, and preferences Dexter learns from your conversations. Write your preferences directly. Click Preferences at the bottom of the Dexter sidebar. In the Dexter preferences dialog, describe how you’d like Dexter to work (up to 4,000 characters) and click Save. The change applies to all new conversations in the factory. View the full preferences file opens the complete rules entry on the Knowledge Base page. Only you change this text — Dexter reads it but can’t edit it. Or tell Dexter in conversation. State a preference 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.” Dexter records durable preferences you state under Learned preferences in the rules entry — during its background pass, or right away if you ask it to update memory. It records what you say you want, not guesses about your habits. To drop a learned preference, say so just as plainly — “Forget the rule about ISO dates.” If the rule is in the text you wrote yourself, remove it in Preferences instead. When a learned preference conflicts with what you wrote in Preferences, what you wrote wins. The rules entry appears on the Knowledge Base page, so you can read exactly what Dexter is operating under at any time.

​

Scope

• Per-factory. Rules apply to a single Factory. 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, 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, 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 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, add it in Preferences or 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 an outline 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, remove it in Preferences or 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.