Skip to content

Institutional memory — teaching DXDT

DXDT remembers what your team teaches it. Every taught fact is stored with attribution and grounds every future run — chat answers, Pulse scans, resilience analysis, and plan reviews all take your team's knowledge into account, citing it when they use it.

What makes a good taught fact

Durable, standalone statements about your environment:

  • "Staging DB failovers on Sunday nights are expected — planned DR drill."
  • "payments-prod must never scale below 3 replicas."
  • "The SRE team owns everything in the platform- projects."

What not to teach: one-off session details, anything speculative, and never secrets or credentials — memory is injected into agent context, it is not a vault.

Four ways to teach

  1. Correct the agent in conversation. When you tell DXDT it's wrong about something durable ("no — that failover is expected"), it saves the correction itself and confirms what it learned and from whom.
  2. The teach button in the chat composer — type the fact (or use the text already in the composer) and click the book icon.
  3. The teach button in a war room — the same book icon next to send. Mid-incident is when tribal knowledge gets said out loud ("this failover takes ~4 minutes, don't page twice") — capture it the moment it's spoken.
  4. The Memory page (user menu → Memory) or POST /api/learnings — the explicit path, also where facts are reviewed.
  5. The CLI — dxdt teach "payments-prod must never scale below 3 replicas" (or /teach inside the interactive session). Handy for capturing a fact in the same terminal where you just learned it.

DXDT also writes memory from its own verified work: when a finding is resolved through the resolution wizard and the fix is confirmed, the resolution is saved as a learning — the next scan knows this class of issue was fixed and how.

Duplicates are detected automatically; re-teaching a retired fact reactivates it.

Attribution and citations

Every fact records who taught it and when, and DXDT cites that when the fact shapes an answer: "per dana (Jun 2026), Sunday failovers are expected." Attribution is what keeps memory trustworthy — you always know where a belief came from.

Reviewing and retiring

The Memory page shows everything DXDT knows about your organization: systems and dependencies mapped, incidents witnessed, and every taught fact with its attribution. Retire facts that stop being true (retired facts stop influencing runs but are kept for the record and can be reactivated). Admins can edit fact text via the API.

Best practices

  • Name things explicitly. "The replica" won't mean anything in six months; "sql-replica-ew1" always will.
  • Teach the why when it matters. "We keep 3 replicas because of the March 2026 incident" makes the fact self-justifying.
  • Retire aggressively. Memory that's wrong is worse than no memory — a monthly two-minute sweep of the Memory page keeps it sharp.
  • Watch the counter. The Morning Report shows how much your team taught each week. A growing memory is a team compounding its operational knowledge instead of losing it to turnover.