Ongoing

Aegis — Controlled Remediation Platform

Solo Developer · 2026 · Ongoing · 1 person · 3 min read

Designing an auditable workflow for detecting service failures, proposing safe remediation, requiring human approval, and verifying recovery.

Overview

Aegis is a learning project about the backend boundaries around operational automation. The public repository currently documents the first Go and REST backend slice, its planned storage and observability, and a rule that each feature needs code, tests or a reproducible failure case, operational signals, and a short learning note.

Problem

Automated recovery can make an incident worse when the system cannot explain what it detected, what it plans to change, or whether the service recovered. Aegis explores a controlled lifecycle that keeps detection, approval, remediation, and recovery verification explicit.

Constraints

  • Solo learning project with a deliberately small first backend slice
  • Remediation safety rules belong in the backend, not only in a future UI
  • Every feature should have a test or reproducible failure case and evidence that it ran
  • The public repository is still in active design and implementation

Approach

I started by defining the incident lifecycle and the first vertical API slice: health, service registration, signals, incident creation, and incident lookup. The planned backend uses Go, a REST API, PostgreSQL, background workers, and structured observability through logs, Prometheus metrics, and OpenTelemetry.

Key Decisions

Require human approval before remediation

Reasoning:

Operational automation should be inspectable and reversible. Approval is an explicit boundary between a proposed action and a potentially harmful change.

Alternatives considered:
  • Fully automatic remediation
  • Manual operations with no recorded proposal

Build the backend vertical slice before the UI

Reasoning:

The safety model and API contract should be exercised independently of a presentation layer. A later UI can remain API-facing while the backend owns the rules.

Alternatives considered:
  • Start with a dashboard and add the backend later
  • Put remediation rules in the client

Treat operational evidence as part of feature completion

Reasoning:

Tests alone do not show how an operational workflow behaves. Logs, metrics, and short explanations make the system easier to inspect while learning.

Alternatives considered:
  • Add observability after all features are complete

Tech Stack

  • Go
  • REST / JSON
  • PostgreSQL
  • Prometheus
  • OpenTelemetry
  • Background workers

Result & Impact

  • 6 planned endpoints across health, services, signals, and incidents
    Initial API slice
  • Human approval before remediation
    Safety boundary
  • Active learning project; implementation is ongoing
    Public status

Aegis is helping me practice backend design for failure-prone systems: clear state transitions, explicit approval, recovery checks, and operational evidence. Its current value is in making those boundaries concrete and reviewable, not in claiming a production-ready incident platform.

Learnings

  • Reliability workflows need explicit state and ownership rather than a single retry loop
  • Safety constraints should be visible in the API and data model
  • Observability is part of the implementation contract for operational tooling
  • Small vertical slices make it easier to validate architecture before adding UI

🔗 View the public repository on GitHub

Current direction

The repository starts with a small, explicit API surface and grows toward an auditable incident lifecycle:

  1. Detect a service signal.
  2. Record an incident.
  3. Propose a remediation.
  4. Require approval.
  5. Run the action and verify recovery.

The project is intentionally presented as ongoing work. The repository README tracks the first backend slice and the evidence expected for each feature.

All projects