DORI Experience
Map → Evidence → Observability → Advisory → Recommendation
Designed to make the first Community workflow concrete without claiming risky automation or invasive scanning.
Map
Hosts, services, endpoints, DNS/routes, monitors, and relationships.
Evidence
TLS, backup, monitoring, ownership, update, and service facts.
Observe
Coverage, freshness, telemetry, readiness, and degraded states.
Advise
Patch/update pressure and risk surfaced without mutation.
Recommend
DORI explains the next safe improvement and why it matters.
DORI is guided Operational Intelligence, not a chatbot bolted onto a dashboard
DORI helps users understand what happened, why it matters, what to do next, and what to improve next.
DORI is not a replacement for ODIN, a generic chat window, a ticketing system, a monitoring platform, a CMDB, or a reporting tool. DORI is the guided experience layer for Technology Health.
It should make operational context easier to understand, but it should not hide uncertainty, invent missing evidence, or bypass governance.
DORI principles
DORI should be:
- understandable;
- actionable;
- manageable;
- enjoyable;
- evidence-aware;
- confidence-building.
Example DORI guidance
The public-facing document service has an available update and its restore validation is stale. Because this service is externally reachable, update risk matters. Validate restore first, confirm the backup target is current, then schedule the update during a maintenance window. Afterward, confirm monitor recovery, record the new version, and attach the result as evidence.
The value is not that DORI sounds clever. The value is that DORI ties evidence to a practical next step.
Reviewer questions
- Is DORI useful without over-explaining modes?