Skip to main content

Internal Knowledge

The Feed internal knowledge view in Knowledge Sources lets you supply OpsWorker with the documentation your team already maintains. Once connected, the AI references this content during investigations and chat sessions.

What to Feed​

Good candidates for internal knowledge:

  • Runbooks — "How to recover from a Redis primary failover", "Steps to drain a node during planned maintenance"
  • Postmortems — "SEV-1 2025-09 outage: root cause and remediation"
  • Architecture docs — service topology, data flow diagrams, integration boundaries
  • Onboarding guides — common gotchas for new engineers on your stack
  • Policy documents — what production access requires, how change management works

What NOT to feed:

  • ❌ Live configuration (the cluster is the source of truth — OpsWorker reads it directly)
  • ❌ Stale or contradictory docs (the AI can't tell which is correct)
  • ❌ Secrets, credentials, or sensitive customer data
  • ❌ Real-time information (alerting status, incident timelines)

How Internal Knowledge Is Used​

When an investigation runs or you ask a question in chat, OpsWorker searches connected internal knowledge for relevant content. Matches are loaded into the AI's context window. The AI then:

  • Quotes or paraphrases the relevant section when answering
  • Links to the original source so you can verify
  • Uses runbook procedures when generating remediation recommendations — if your runbook says "always verify backups before failover", that step shows up in the recommendation

Internal knowledge does not replace OpsWorker's live data gathering. The AI still inspects pods, logs, events, and metrics; internal knowledge is added context, not a substitute.

Keeping Knowledge Fresh​

Stale runbooks generate stale recommendations. Two failure modes to watch for:

  1. The document was correct when written, but the system changed. Periodic review (quarterly is a good cadence) catches this.
  2. The document is correct but ambiguous. If the AI quotes a runbook step and engineers disagree on what it means, the runbook needs rewriting — not just for OpsWorker, but for humans too.

Scope​

Internal knowledge is organization-scoped by default — accessible from any cluster in your org. If you have cluster-specific runbooks, you can scope them when feeding them in (where supported by the UI).

Best Practices​

  • Feed cleaned-up docs, not raw exports. Strip outdated sections before uploading. Less is more — the AI does better with focused content than sprawling dumps.
  • Use clear titles. "Postgres failover runbook" is better than "PG-FO-2024-rev3.md".
  • Index, don't dump. A 200-line focused runbook is more useful than 2000 lines of mixed history and procedure.
  • Pair with rules. Best-practice rules cover the constraints; internal knowledge covers the procedures. Use both.

Next Steps​