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 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 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. Two entries are always loaded — the index and your rules — and 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 in the Knowledge Base views — 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. 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.

​

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.

​

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 are read the same way, as shared background context.
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. 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.

​

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.

​

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 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.