Skip to main content

Overview

Organization memories are a shared layer of knowledge that Dexter draws on across every Factory in your organization. They’re curated centrally by your organization’s administrators and available to Dexter in every conversation, alongside the per-factory knowledge base. They can include Markdown guidance, JSON references, Python helpers, and PNG or SVG assets such as an organization logo. Use them for anything that’s true across the whole organization and shouldn’t be re-taught in every factory:
  • Corporate standards, naming conventions, and reporting formats
  • Shared vocabulary and acronyms
  • Cross-site conversion factors, costing conventions, and calendar rules
  • How the organization wants Dexter to behave by default (tone, escalation, sign-off norms)
  • References to systems and data sources used across sites (ERP, MES, PLM)

How They Differ from Factory Memories

Because organization memories are shared and centrally governed, they are read-only from the factory side: you can’t edit them from a Dexter conversation, and they don’t appear in the per-factory Knowledge Base views. If something in there is wrong or missing, ask your organization’s administrator to update it.
Only organization administrators can add, edit, or remove organization memories — the curation surface sits at the organization level, outside any single factory.

How Dexter Uses Them

Dexter keeps a catalog of organization memories in view, alongside a short orientation to the factory knowledge base and the factory’s complete rules. The catalog lists every file in the normal small set. Markdown entries include a title and short opening synopsis when available; other entries include a readable filename and file type. Dexter uses the catalog to identify and open relevant guidance or assets without loading every file into every conversation. When organization guidance conflicts with a factory rule, Dexter follows your factory rule and points out the conflict. When organization memory and factory knowledge disagree about an operational fact, Dexter surfaces the discrepancy and asks you which information is current. Resolutions that need to stick land in one of two places:
  • Factory-specific exception — Dexter records it in the factory knowledge base.
  • The organization-level entry is wrong — send the correction to your administrator.
Repetition is the signal for promotion: if you find yourself teaching the same correction, convention, or acronym in more than one factory’s knowledge base, ask your administrator to move it into organization memories once, for everyone.

Limits and Caveats

  • Not browsable from a factory. Organization memories don’t show up in the Knowledge Base tab. To find out what’s in there, ask your administrator — or ask Dexter what it’s operating on for a given topic.
  • Read-only in conversation. Dexter will not modify organization memories, even if you ask. Requests to change them get pointed at your administrator.
  • Tenant-wide by definition. Don’t put factory-specific detail in them — it bleeds into factories where it doesn’t belong. Keep those entries in the factory knowledge base.
  • Changes apply by the next conversation. Dexter refreshes the catalog when its conversation context refreshes and when a new conversation starts. An admin edit may not appear immediately in a conversation already in progress.

When to Request an Organization-Memory Change

Ask your administrator to update organization memories when:
  • The same correction keeps landing in more than one factory’s knowledge base
  • A standard, unit, or naming convention has changed organization-wide
  • A shared system (ERP, MES, PLM) has been renamed, replaced, or restructured
  • The organization wants Dexter to behave differently by default across all factories
For anything narrower than that, keep it in the factory knowledge base.