Concepts

How RunLore is designed, and why a deployment gets better at your platform over time instead of re-deriving the same diagnosis every week. These pages explain the model; they are not setup guides — Integrations and Configuration are.

• Design — what RunLore is for, its goals and non-goals, the three pillars (React, Investigate, Learn), and the autonomy ladder. Start here.
• Architecture — the same flow as a diagram, with the read-only boundary drawn on it.
• Learning Loop — the heart of it: how a verified finding becomes recallable knowledge, how recall is kept trustworthy, and what makes a wrong entry decay instead of persisting.
• Data Sources — the signal model: which tool each backend unlocks, behind which interface. Every source is pluggable and none is assumed.
• Reviewing Knowledge — RunLore never writes to the catalog directly; it opens pull requests. This is what you are agreeing to when you merge one.
• Knowledge Commons — why a fresh deployment starts useful instead of empty, and what the shared catalog does and does not contain.
• Prior Art — where RunLore sits among the other AI-SRE tools, stated honestly.