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.

3 tiers, phased delivery 1 change, one reviewed PR 1 lab, run as production

Delivery snapshot

Delivery snapshot, generated from the backlog - as of 2026-07-30.

27/28 Tier 1 - Now, done 55/110 Tier 2 - Next, done 117/297 Tier 3 - Later, done

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.

Detect, then approve Automation observes and proposes; a human gate stands before anything destructive or irreversible. The machine does the tedious detection; the person makes the call.
Earned autonomy A capability graduates from "suggest" to "act under approval" to "act on its own" only as it proves itself, with every outcome recorded. Trust is earned by evidence, not granted by default.
Paved road The safe, correct way to do something is made the easiest way - shared libraries, templates, and guardrails - so doing it right is the path of least resistance.
Roll forward, not rollback A partial failure cleans up forward to a consistent state rather than leaving half-built wreckage; the decommission path reverses every step provisioning took.
Fail closed by default When a gate cannot confirm that proceeding is safe, it denies rather than allows. A false stop is preferred to a false go.
Gated triage loop The newest pattern, embodied by the AIOps work: collect the signals, triage them with local-first inference (escalating to a stronger model only for the hard cases, behind a cost gate), and surface a proposed next step - never an automatic action. It composes detect-then-approve, earned autonomy, and fail-closed into one loop that reads, reasons, and proposes, but only ever acts through a human gate.

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:

Alerting rides the platform it watches Notifications run on the same platform they monitor, so a full-platform outage can mute its own alerts. The gap is acknowledged rather than hidden, with an out-of-band notification path as the recorded follow-up.
No new plugins on the automation controller The controller declines convenience plugins to keep its attack surface small, and accepts a more manual trigger wiring as the deliberate, permanent cost of that posture.
Fail-closed blocks legitimate work Gates that deny on uncertainty will sometimes stop legitimate work when a dependency is down. That false stop is the accepted price of never having a false go.

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.