Roadmap · how the platform is planned
The plan behind the platform
This is the public, genericized roadmap for AutomationLab - the reasoning a finished repository cannot show on its own: how work is tiered and prioritized, the design patterns it is built on, and the trade-offs made on purpose and recorded honestly. Internal specifics are deliberately left out; what stays is the engineering thinking.
Delivery snapshot
Delivery snapshot, generated from the backlog - as of 2026-07-30.
Recently delivered
- Proved disaster recovery for real: deliberately destroyed and restored the secrets store end to end, back in service in 97 seconds, with every dependent verified. (2026-07-12)
- Traced a three-day silent backup outage to a certificate-pin mismatch and added an active staleness check so it can't recur unseen. (2026-07-11)
- Backup staleness now raises an active alert instead of only appearing in a report someone has to remember to read.
- Standardized secret masking across every pipeline, so credentials never surface in a build log.
- Documented every automation role with a README and its defaults, turning tribal knowledge into something a reader can follow.
- Backup freshness now tells deleted guests apart from genuinely stale ones, so the alerts stay trustworthy.
- Factored a shared pipeline library so a new pipeline is composed from vetted parts, not copy-pasted.
- Dependency updates arrive as reviewed pull requests from an update bot - drift and known-vulnerable versions become changes to review, not surprises to discover.
How this roadmap works
Work is organized into three tiers - Now, Next, and Later - by dependency and leverage, not by whim. A tier is not a deadline; it is a statement of what has to be true before the next thing is worth doing. Foundational capabilities (provisioning, GitOps, guardrails) come first because everything above them assumes they exist.
Every item is a why before a what: it states the problem and the reason it is worth solving before the mechanism. Every change lands as one reviewed pull request behind required gates, and every shipped capability has a definition of done, a runbook, and - where a real decision was made - an architecture decision record.
Tier 1 - Now: the foundation
The base the rest of the platform stands on - now complete, every foundation item closed.
- Provisioning as a pipeline, not a checklist. A request flows through address allocation, infrastructure-as-code, monitoring registration, configuration, a human approval gate, and enrollment - rolling forward on partial failure and reversing cleanly on decommission.
- Config-as-code, reviewed like code. The cluster and the automation controller are declared in git and reconciled continuously; nothing reaches the platform except through a branch and a PR.
- Guardrails in the merge path. Lint and security scanning run as required checks, and a pre-commit layer catches problems before they are even pushed.
- Process artifacts. Decisions are recorded as ADRs, emergencies get blameless postmortems, a written definition of done keeps "finished" honest, and every pipeline has an operator runbook.
- A shared pipeline library. Common structure and helpers are factored out so a new pipeline is composed, not copy-pasted.
- Dependencies stay current on their own. An update bot opens reviewed pull requests for new versions, so drift and known-vulnerable dependencies arrive as changes to review rather than surprises to discover.
- The public artifacts carry their own CI. The published site is validated by a second, independent pipeline before it ships - separate from the internal one, so the public face has its own green checks.
- Recovery proven, not assumed. The foundation's capstone was a live disaster-recovery game day: the secrets store - the platform's single most critical dependency - was deliberately destroyed and restored from backup end to end, back in service in 97 seconds, with every dependent system verified to recover and the findings folded back into the runbook. "We back up" became "we have restored, on the clock."
Tier 2 - Next: observability and operations
Turning a platform that runs into one that watches, repairs, and triages itself. Substantially shipped, still advancing.
- Metrics, dashboards, and logs unified into a single operational view, with alerting rules tuned so every firing alert is a real one, not noise.
- A monitoring coverage audit so "is this actually being watched?" has a provable answer instead of an assumption.
- Self-heal enhancements that classify a failure, apply an OS-aware fix, and record every outcome so remediation is auditable.
- A gated AIOps triage loop - now live end to end. Overnight alerts, failed builds, and backup and monitoring signals are collected into one normalized view and triaged into a single morning digest: each finding classified, correlated against history, its noise suppressed against the loop's own memory of what it has already seen, and given a proposed next step. Inference runs local-first, escalating to a stronger model only for the hard cases behind a cost gate; nothing acts on its own - every fix is a proposal a human approves, fail-closed throughout.
- Reporting and digest pipelines and a single-pane reports portal, so the platform's state is legible at a glance.
- Recovery and trust as tested operations - restore-and-reconcile pipelines, and certificate lifecycle extended so internal services present certs issued by the lab's own certificate authority. The disaster-recovery game day that anchored this line - destroy and restore the secrets store to prove the runbook rather than assume it - has now run; it closed out the foundation tier above, and the rest of this line is still advancing.
- An internal platform API as the anchor that ties the automation surface together programmatically.
Tier 3 - Later: the advanced platform
Where the platform starts to reason about itself. Planned.
- Resource orchestration and right-sizing - the platform adjusting its own footprint to load rather than being hand-tuned.
- Chaos engineering with automated adjudication - deliberately breaking things in a controlled window and judging the blast radius, to prove resilience instead of assuming it.
- Paved-road platform-engineering projects that make the safe path the easy path for whatever runs on the platform next.
- A self-heal learning ladder that graduates remediation from suggest, to act under approval, to act autonomously as it earns trust.
- The AIOps loop graduates from triage-and-propose toward agentic, multi-step analysis and gated automated fixes - earning more autonomy only as its track record proves it - alongside the remaining security and AI pipelines that extend the same guardrails to more of the estate.
Design patterns
A handful of patterns recur across the roadmap; they are the load-bearing ideas, not decoration.
Recorded trade-offs
Decisions are recorded honestly, including their costs - captured as architecture decision records so the reasoning survives after the context is forgotten. A few representative ones, genericized:
How the platform proves itself
The roadmap is exercised by real workloads, not demos. A self-hosted, database-backed application runs on the platform as a proving ground - the workload that exercises schema migrations, scheduled data pipelines, and stateful deploys end to end, so the platform is tested against production-shaped problems rather than toy ones.
And the discipline is uniform: branch per change, one reviewed PR, required gates, a runbook per pipeline, a decision record per real choice. The roadmap is not a wish list - it is a plan run the way an engineering organization runs one.