Platform Maturity Matrix
Platform Maturity Matrix
Purpose: Map every enterprise platform capability to its current state, target state, owning plan, and DORA metric it serves. This is the master scorecard for the pal-e platform. The gap between "current" and "target" is the roadmap. Every row exists to move a DORA number.
Axiom: DORA is the reason this platform exists. See
dora-framework for the full framework, baseline measurements, and targets. The four metrics — Deployment Frequency, Lead Time, Change Failure Rate, MTTR — are the measure. This matrix is the means.Operating thesis: This platform exists to prove that one human architect + AI agent orchestration can build and operate infrastructure that delivers at enterprise DORA velocity. The SOPs, hooks, enforcement architecture, and pal-e-docs knowledge system ARE the institutional knowledge. Claude agents are the workforce. DORA metrics prove the system works.
Current DORA standing (2026-03-01 baseline):
| Dimension | DF | LT | CFR | MTTR | Overall |
|---|---|---|---|---|---|
| App Pipeline | Elite | Elite | High | High | <strong>High</strong> |
| Infra Pipeline | Medium | Medium | High | Medium | <strong>Medium</strong> |
| Agent Velocity | Elite | High | High | High | <strong>High</strong> |
| <strong>Platform Overall</strong> | <strong>High</strong> | <strong>Medium-High</strong> | <strong>High</strong> | <strong>Medium</strong> | <strong>Medium-High</strong> |
The 50-Engineer Number
A traditional 50-person engineering org that operates at enterprise maturity typically staffs:
| Role | Headcount | Responsibilities |
|---|---|---|
| Platform Engineers | 3–5 | Build and maintain IaC, CI/CD pipelines, service mesh, container orchestration, developer tooling |
| SRE / DevOps | 2–3 | On-call rotation, incident response, capacity planning, SLO enforcement, runbook maintenance |
| Security Engineer | 1–2 | Policy-as-code, vulnerability scanning, compliance, secrets management, penetration testing |
| Engineering Manager | 1 | Prioritization, cross-team coordination, DORA tracking, hiring |
| <strong>Platform subtotal</strong> | <strong>7–11</strong> | <strong>These people maintain the platform for everyone else</strong> |
| Application Engineers | 39–43 | Build features, consume the platform, ship product |
The pal-e model replaces both groups. The 7–11 platform maintainers are replaced by Betty Sue (coordinator) + dev/QA agents operating under SOPs with hook enforcement. The 39–43 application engineers are replaced by spawned dev agents working from plans, bounded by issues, reviewed by QA agents. The human (Lucas) operates as architect + CEO — making decisions, approving plans, and setting direction. The agents execute.
What makes this viable now (and wasn't 2 years ago):
- MCP gives agents real tool access (Forgejo, Woodpecker, pal-e-docs, Playwright)
- Hooks enforce constraints that agents can't bypass (no plan = no agent, issue template enforcement, PR review-fix loops)
- pal-e-docs is queryable institutional memory — agents don't start from zero
- SOPs codify the "how" so agents don't need judgment calls on process
- DORA metrics prove (or disprove) that this model delivers at enterprise velocity — see
dora-framework
Maturity Matrix
Legend: Done = operational. In Progress = plan exists, work started. Planned = plan exists, work not started. Needs Plan = no plan yet. N/A = not applicable at current scale.
DORA column key: DF = Deployment Frequency, LT = Lead Time, CFR = Change Failure Rate, MTTR = Mean Time to Recovery.
1. Infrastructure as Code
| Capability | DORA Target | Enterprise Target | Current State | Status | Plan / Phase | Operated By |
|---|---|---|---|---|---|---|
| Declarative infrastructure | DF, LT | All infra defined in code, no manual changes | OpenTofu for cluster, SaltStack for host. 100% code-managed. | <strong>Done</strong> | — | Dev agents |
| Modular Terraform | LT, CFR | Reusable modules, versioned, registry-hosted | 828-line monolithic main.tf in pal-e-platform | Planned | <code>plan-2026-02-26-tf-modularize-postgres</code> Phase 1 | Dev agents |
| State management | CFR | Remote backend with encryption, versioning, locking | Kubernetes secrets backend with locking. No versioning, no encryption at rest beyond etcd. | <strong>Done</strong> (adequate) | — | Automated |
| State backup | MTTR | Versioned bucket with cross-region replication | None | Planned | <code>plan-2026-02-26-tf-ci-team-hardening</code> Phase 1 | Automated (CronJob) |
| Off-host backup | MTTR | Cross-region or cross-provider replication | All backups on same NVMe | Needs Plan | Seed in TF CI plan — MinIO to Backblaze B2 or Hetzner Object Storage | Automated (mc mirror) |
| Drift detection | CFR | Scheduled plan, alerts on unexpected diff | None | Needs Plan | Seed in TF CI plan Phase 5 | Automated (CronJob + alert) |
| Host management | CFR, LT | Configuration management with continuous enforcement | SaltStack: 27 states, GPG-encrypted pillar, nftables firewall | <strong>Done</strong> | <code>plan-2026-02-26-salt-host-management</code> (complete) | Salt (automated) |
2. CI/CD Pipeline
| Capability | DORA Target | Enterprise Target | Current State | Status | Plan / Phase | Operated By |
|---|---|---|---|---|---|---|
| App CI (build + push) | DF, LT | Automated build on push, image push to registry | Woodpecker CI builds all service images, pushes to Harbor | <strong>Done</strong> | — | Automated |
| App CD (deploy) | DF, LT | GitOps: image tag change triggers deployment | ArgoCD + Image Updater. Git write-back to kustomization.yaml. | <strong>Done</strong> | — | Automated |
| Infra CI: validation | CFR | fmt, validate, lint, security scan on every PR | None — manual tofu plan from laptop | Planned | <code>plan-2026-02-26-tf-ci-team-hardening</code> Phase 2 | Automated (Woodpecker) |
| Infra CI: plan-on-PR | CFR, LT | tofu plan output posted as PR comment | Manual — developer runs plan, pastes output | Planned | <code>plan-2026-02-26-tf-ci-team-hardening</code> Phase 3 | Automated (Woodpecker) |
| Infra CD: apply-on-merge | DF, LT | Merge to main triggers tofu apply. No manual applies. | Manual — tofu apply from laptop | Planned | <code>plan-2026-02-26-tf-ci-team-hardening</code> Phase 4 | Automated (Woodpecker) |
| Pipeline-as-code | LT | All CI/CD defined in .woodpecker.yaml / .github/workflows | App pipelines: yes. Infra pipelines: not yet. | Partial | <code>plan-2026-02-26-tf-ci-team-hardening</code> Phase 2 | Dev agents |
| Rollback mechanism | MTTR | git revert + auto-apply, or Helm rollback | Manual git revert + manual re-apply | Planned | <code>plan-2026-02-26-tf-ci-team-hardening</code> Phase 4 | Automated (pipeline) |
3. Service Deployment
| Capability | DORA Target | Enterprise Target | Current State | Status | Plan / Phase | Operated By |
|---|---|---|---|---|---|---|
| Centralized deployment conventions | DF, LT | Platform base inherited by all services (HPA, probes, resource limits) | Per-repo k8s/ directories, copy-paste conventions | In Progress | <code>plan-2026-02-26-kustomize-service-bases</code> Phase 1 (PR open) | Dev agents |
| Horizontal Pod Autoscaling | MTTR | HPA on every service, tuned per workload | None | In Progress | <code>plan-2026-02-26-kustomize-service-bases</code> Phase 1 (in base, disabled by default) | Overlay config |
| Secrets in GitOps | CFR, LT | SOPS-encrypted secrets in git, decrypted at sync time | Manual kubectl create secret | Planned | <code>plan-2026-02-26-kustomize-service-bases</code> Phase 2 | Dev agents + KSOPS |
| Environment-aware deployments | CFR | One service definition, multiple environments (dev/staging/prod) | Flat var.services with duplicate entries for dev/prod | Planned | <code>plan-2026-02-26-kustomize-service-bases</code> Phase 3 | Dev agents |
| Service onboarding automation | DF, LT | One config entry provisions entire service stack | var.services for_each creates 7 resources per service. Manual k8s/ manifests. | Partial | Full automation after Kustomize Phase 3 | Dev agents |
| Container registry | CFR | Private registry with vulnerability scanning | Harbor deployed. No vulnerability scanning enabled. | Partial | Needs Plan (Harbor Trivy integration) | Automated (Harbor) |
4. Networking & Security
| Capability | DORA Target | Enterprise Target | Current State | Status | Plan / Phase | Operated By |
|---|---|---|---|---|---|---|
| Network segmentation (k8s) | CFR | Default-deny NetworkPolicies per namespace | Flat pod network, no policies | Planned | <code>plan-2026-02-26-network-security-hardening</code> Phase 1 | Dev agents |
| Host firewall | CFR | Default-deny inbound, code-managed rules | nftables code-managed via Salt. NOT YET APPLIED (operator must apply with revert timer). | <strong>Done</strong> (pending apply) | <code>plan-2026-02-26-salt-host-management</code> Phase 3 (complete) | Salt (automated) |
| Tailscale ACL | CFR | Least-privilege per-service ACLs | Wide open (*:*:*) | Planned | <code>plan-2026-02-26-network-security-hardening</code> Phase 2 | Dev agents |
| TLS everywhere | CFR | All services TLS-terminated, no plaintext | Tailscale funnels handle TLS termination for all ingress | <strong>Done</strong> | — | Automated (Tailscale) |
| Secrets management | CFR | Encrypted at rest, audited access, rotation policy | Salt GPG pillar for host secrets. Plaintext tfvars for TF. Manual kubectl for app secrets. | Partial | Multiple: Salt (done), SOPS (Kustomize P2), Woodpecker secrets (TF CI P3) | Mixed |
| Secret rotation | CFR | Automated rotation on schedule | Manual. Rotation registry in Salt pillar tracks dates. | Needs Plan | Seed in Kustomize plan | Automated (future CronJob) |
| Vulnerability scanning | CFR | Container + dependency scanning on every build | None | Needs Plan | — | Automated (Trivy/Grype in CI) |
| Policy as code | CFR | OPA/Kyverno guardrails (no privileged, resource limits required) | None | Needs Plan | — | Automated (admission controller) |
| RBAC / least privilege | CFR | Per-team kubeconfig, scoped roles | Single admin kubeconfig | Planned | <code>plan-2026-02-26-tf-ci-team-hardening</code> Phase 5 | Dev agents |
5. Observability
| Capability | DORA Target | Enterprise Target | Current State | Status | Plan / Phase | Operated By |
|---|---|---|---|---|---|---|
| Metrics collection | MTTR | Prometheus scraping all services via ServiceMonitor | Prometheus deployed, ServiceMonitors on all services | <strong>Done</strong> | — | Automated |
| Log aggregation | MTTR | Centralized logs, searchable, retained | Loki + Promtail deployed. 7-day retention. | <strong>Done</strong> | — | Automated |
| Dashboards | MTTR, CFR | Golden signals per service, infrastructure overview | Grafana deployed. No custom dashboards. | Planned | <code>plan-2026-02-25-platform-observability</code> Phase 4 | Dev agents |
| Alerting | MTTR | SLO-based alerts, PagerDuty/Slack integration | Alertmanager deployed but unconfigured. No alert rules. | Planned | <code>plan-2026-02-25-platform-observability</code> Phase 3 | Dev agents |
| SLOs / SLIs | CFR, MTTR | Defined per service, measured, dashboarded | None defined | Planned | <code>plan-2026-02-25-platform-observability</code> Phase 2 | Betty Sue (docs) |
| Distributed tracing | MTTR | Jaeger/Tempo, request-level visibility | None | Needs Plan | — | Automated |
| Incident management | MTTR | Defined process, post-mortems, tracked MTTR | Ad-hoc. Incident log exists on project page. No formal process. | Needs Plan | — | Betty Sue + agents |
| DORA metrics | ALL | Dashboard, tracked weekly, improvement targets | Manual baseline established (see <code>dora-framework</code>). No automated dashboard. | Planned | <code>plan-2026-02-26-tf-ci-team-hardening</code> Phase 5 + <code>dora-framework</code> | Automated (pipeline data) |
6. Environment Management
| Capability | DORA Target | Enterprise Target | Current State | Status | Plan / Phase | Operated By |
|---|---|---|---|---|---|---|
| Dev environment | CFR | Isolated cluster, safe to break | Single prod cluster only | Planned | <code>plan-2026-02-27-environment-isolation-secret-boundaries</code> Phase 1 | Salt + Dev agents |
| Environment promotion | CFR | Dev → staging → prod with gates | No promotion workflow | Needs Plan | Depends on dev cluster (Environment Isolation P1) | Automated (pipeline) |
| Per-environment secrets | CFR | Separate encryption keys per environment | Single set of secrets | Planned | <code>plan-2026-02-27-environment-isolation-secret-boundaries</code> Phase 2 | Dev agents |
| Feature flags | DF, CFR | Runtime feature toggling without deploys | None | Needs Plan | — | N/A (assess at scale) |
7. Disaster Recovery
| Capability | DORA Target | Enterprise Target | Current State | Status | Plan / Phase | Operated By |
|---|---|---|---|---|---|---|
| DR runbook | MTTR | Tested quarterly, RTO/RPO documented | None written | Planned | <code>plan-2026-02-26-tf-ci-team-hardening</code> Phase 1 follow-up | Betty Sue (docs) |
| Database backup | MTTR | Automated, verified, point-in-time recovery | Litestream replicates pal-e-docs SQLite to MinIO. No verification testing. | Partial | Needs Plan (restore testing CronJob) | Automated |
| GPG key backup | MTTR | Physical backup in secure location | Not done | Open TODO | <code>todo-gpg-physical-backup</code> | Lucas (physical) |
| Off-host replication | MTTR | Critical data replicated to separate physical location | All data on single NVMe | Needs Plan | Seed in TF CI plan | Automated (mc mirror) |
8. Developer Experience & Governance
| Capability | DORA Target | Enterprise Target | Current State | Status | Plan / Phase | Operated By |
|---|---|---|---|---|---|---|
| Onboarding docs | LT | Self-serve, < 1 hour to first PR | SERVICE_ONBOARDING.md exists. No infra onboarding. | Partial | <code>plan-2026-02-26-tf-ci-team-hardening</code> Phase 5 | Betty Sue (docs) |
| Cost tracking | — | Per-service cost attribution, budget alerts | None (self-hosted, hardware amortized) | N/A | Revisit if multi-cloud | — |
| Dependency scanning | CFR | Automated (Renovate/Dependabot), PR on update | None | Needs Plan | — | Automated |
| License compliance | — | Automated scanning, policy enforcement | None | Needs Plan | — | Automated |
| Change management | CFR | PR review required, approval gates, audit trail | PR reviews via agent review-fix loop. No required approvals in Forgejo. | Partial | Needs Plan (Forgejo branch protection rules) | QA agents + Lucas |
9. AI Agent Orchestration (unique to pal-e)
| Capability | DORA Target | Enterprise Target | Current State | Status | Plan / Phase | Operated By |
|---|---|---|---|---|---|---|
| Knowledge system | LT, MTTR | All plans, SOPs, decisions, incidents queryable by agents | pal-e-docs: 160+ notes, MCP-accessible, tagged, project-linked | <strong>Done</strong> | <code>plan-2026-02-28-knowledge-system-consolidation</code> (refinement) | Betty Sue |
| Agent enforcement | CFR | No agent runs without plan context. Tool restrictions enforced. | Hooks enforce plan-slug requirement, issue template, tool restrictions | <strong>Done</strong> | — | Hooks (automated) |
| PR review-fix loop | CFR | Automated review, fix, re-review until clean pass | QA agent reviews, dev agent fixes. Loop operational. | <strong>Done</strong> | — | QA + Dev agents |
| Agent DORA metrics | ALL | Measure agent velocity: PR cycle time, defect rate, rework rate | Manual baseline in <code>dora-framework</code>. No automated collection. | Planned | <code>plan-2026-02-26-tf-ci-team-hardening</code> Phase 5 + future agent DORA plan | Automated (pipeline + Grafana) |
| MCP tool coverage | LT, DF | Agents can operate all platform services via MCP | Forgejo MCP, pal-e-docs MCP operational. Woodpecker MCP in progress. | In Progress | <code>plan-2026-02-28-woodpecker-mcp</code> | Dev agents |
| Agent-driven incident response | MTTR | Agents detect, diagnose, and remediate incidents autonomously | None — incidents are manual | Needs Plan | Depends on: alerting (Observability P3), MCP coverage, runbook automation | Agents (future) |
| Autonomous deployment pipeline | DF, LT | Agent creates plan → issue → branch → code → PR → review → merge → deploy, fully hands-off | Plan → issue → branch → code → PR → review operational. Merge requires Lucas approval. Deploy is manual tofu apply. | Partial | Full autonomy after TF CI Phase 4 (apply-on-merge) + Forgejo branch protection | Agents + Lucas (approval gate) |
Maturity Scorecard
| Domain | Capabilities | Done | In Progress / Planned | Needs Plan | Maturity % | Primary DORA Impact |
|---|---|---|---|---|---|---|
| Infrastructure as Code | 7 | 3 | 3 | 1 | 43% | LT, CFR |
| CI/CD Pipeline | 7 | 2 | 5 | 0 | 29% | DF, LT |
| Service Deployment | 6 | 0 | 5 | 1 | 0% | DF, LT |
| Networking & Security | 9 | 2 | 5 | 2 | 22% | CFR |
| Observability | 8 | 2 | 4 | 2 | 25% | MTTR |
| Environment Management | 4 | 0 | 2 | 2 | 0% | CFR |
| Disaster Recovery | 4 | 0 | 2 | 2 | 0% | MTTR |
| Developer Experience | 5 | 0 | 2 | 3 | 0% | LT |
| AI Agent Orchestration | 7 | 3 | 3 | 1 | 43% | ALL |
| <strong>TOTAL</strong> | <strong>57</strong> | <strong>12</strong> | <strong>31</strong> | <strong>14</strong> | <strong>21%</strong> | — |
Reading: 21% of enterprise capabilities are operational. 54% have plans. 25% need plans. Current DORA standing: Medium-High. Target: High by Q2 2026 (requires TF CI + Observability plans). See
dora-framework for full baseline and targets.What "Done" Looks Like (The DORA Endgame)
When every row in this matrix is green, all four DORA metrics hit Elite:
- Deployment Frequency = Elite: Lucas says "ship feature X" and walks away. Betty Sue creates a plan, agents execute, code deploys automatically. Multiple production deploys per day across all projects.
- Lead Time = Elite: From plan phase to production in under 1 hour. Agent creates branch, writes code, opens PR, QA reviews, dev fixes, merge triggers auto-apply.
- Change Failure Rate = Elite: CI gates, QA review loops, deployment protection, environment promotion, and policy-as-code keep failures below 5%. When CI fails, the agent fixes it in the same session.
- MTTR = Elite: Alerting detects issues in seconds. Agents diagnose using runbooks. Agents apply fix or rollback. Recovery in under 1 hour without human intervention.
The platform IS the 50-person team. DORA proves it.
Needs Plan Inventory
Capabilities marked "Needs Plan" that should become plans when prioritized. Each maps to a DORA metric.
| Capability | DORA Target | Domain | Rough Scope | Depends On |
|---|---|---|---|---|
| Off-host backup replication | MTTR | IaC / DR | mc mirror CronJob to Backblaze B2 or Hetzner Object Storage | TF CI Phase 1 (state backup exists first) |
| Drift detection | CFR | IaC | Scheduled tofu plan, alert on non-empty diff | TF CI Phase 4 (pipeline exists) |
| Vulnerability scanning | CFR | Security | Trivy in Woodpecker pipeline + Harbor scanner | None |
| Policy as code | CFR | Security | Kyverno admission controller, enforce resource limits + no-privileged | None |
| Distributed tracing | MTTR | Observability | Tempo + OpenTelemetry instrumentation | Observability Phase 1 (architecture) |
| Incident management SOP | MTTR | Observability | Define process, severity levels, post-mortem template, tracked MTTR | Alerting (Observability Phase 3) |
| Environment promotion | CFR | Environments | Dev → prod promotion gates, branch-based or image-tag-based | Environment Isolation Phase 1 (dev cluster) |
| Dependency scanning | CFR | DevEx | Renovate on Forgejo, auto-PR for updates | None |
| License compliance | — | DevEx | FOSSA or licensee in CI pipeline | None (low priority) |
| Branch protection | CFR | DevEx | Forgejo branch protection rules: require PR, require CI pass | TF CI Phase 2 (CI exists to gate on) |
| Container registry scanning | CFR | Service Deployment | Harbor Trivy integration | None |
| Database backup verification | MTTR | DR | Scheduled restore test CronJob | None |
| Agent-driven incident response | MTTR | AI Orchestration | Runbook automation: alert → agent diagnoses → agent remediates | Alerting + MCP coverage + runbooks |
| Agent DORA metrics | ALL | AI Orchestration | Measure agent-specific velocity and quality metrics | TF CI Phase 5 (baseline), pipeline data |
Related
dora-framework— the axiom. Defines DORA metrics, baseline, targets, and how every plan maps to the four numbers.project-pal-e-platform— links from project page roadmaptf-best-practices-comparison— the original industry comparison that seeded this matrixtf-team-readiness— the 7 blockers analysisinsight-devops-materializes-at-team-onboarding— why these capabilities emerge together- All active plans — each maps to rows in this matrix and DORA metrics in
dora-framework