Aegis — Controlled Remediation Platform

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

1. Decision 01

   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

2. Decision 02

   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

3. Decision 03

   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

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

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

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