First Proof Loop
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.
Start with a map. Add evidence. Improve with guidance
The first Community proof loop is intentionally practical for home lab users and early adopters.
A user imports or records their environment. ODIN shows a safe map of hosts, services, endpoints, DNS/routes, monitors, backups, and relationships. Evidence attaches to those records: backup posture, certificate state, service health, observability state, update facts, ownership, and coverage.
DORI then explains what matters and recommends the next useful improvement. If no AI provider is configured, DORI can still operate in Guided Mode through structured choices, cards, checklists, templates, and deterministic recommendations.
Loop stages
| Stage | User-visible result |
|---|---|
| 1 | Network Map shows hosts, services, endpoints, DNS/routes, monitors, and relationships. |
| 2 | Asset Registry turns imports/manual entries into curated records. |
| 3 | Evidence attaches TLS, backup, monitor, service, ownership, and update facts. |
| 4 | Observability surfaces monitoring, alerting, telemetry freshness, and monitor coverage. |
| 5 | Patch & Update Advisory highlights stale or risky update candidates. |
| 6 | ODIN cards summarize health, observability, backup, certificate, coverage, and update pressure. |
| 7 | DORI recommends the next practical improvement using Guided Mode if no AI provider is available. |
| 8 | Technology Health moves from unknown to mapped, observed, evidenced, advised, and improved. |
Example scenario
A public-facing document service is running behind a reverse proxy. ODIN shows the route, service, host, monitor, and backup relationship. The service is behind on updates. Backup evidence exists, but restore validation is stale.
ODIN does not immediately mutate the service. It frames the situation:
- the service is externally reachable;
- a newer version is available;
- monitor evidence is current;
- backup evidence exists;
- restore validation is stale;
- ownership is known for the service but missing for one supporting dependency.
DORI recommends the next safe improvement:
Validate restore first. Then schedule the update during a maintenance window. Confirm monitor recovery afterward and attach the result as new evidence.
That is the first proof of Technology Health: better understanding, better evidence, and better decisions.
Reviewer questions
- Does the first workflow feel credible?