OpenSRE keeps a Neo4j-backed map of your service topology — dependencies, ownership, and the affected-service links back to past investigations. It lives in the same Neo4j instance as episodic memory, as a separate domain within it. During an investigation, the agent can query this graph to understand blast radius and dependency chains for a service it has already identified as affected.
:Service nodes — one per service you register, with dependency edges between them.:Episode → :Service links — when an episode's affected components match a known service by name, it gets an AFFECTED edge, connecting past investigations to the topology they touched.This is deliberately a smaller, more honest model than a full CMDB. It's built to answer "what else might this affect?", not to be a general-purpose asset inventory.
The agent queries topology through a dedicated skill (infrastructure-neo4j), and only after it already knows which service is affected — topology isn't loaded speculatively on a vague alert, the same agent-driven principle as episodic memory. If the graph is empty or Neo4j is unavailable, the investigation continues normally without it; topology is optional context, never a hard dependency.
Today, topology is manually maintained — you seed and update :Service nodes and their dependency edges yourself (via the config-service API, or directly in Neo4j), rather than OpenSRE discovering them automatically from your infrastructure. Automatic discovery and continuous topology updates are on the roadmap, not shipped yet — don't design a workflow around auto-discovery existing today.
There's no dedicated topology-editor page in the web console yet. Query and maintain the graph directly (Neo4j Browser at the port from Quick Start, or the config-service API) until a UI lands.