Capabilities
Polo’s scope is divided into 28 capability areas. Each area has a maturity level, and the levels are strict: an area is not called working because code for it exists. This page lists every area with its level and one line on what works today.
The source of truth is docs/CAPABILITIES.md in the repository, which maps every capability to its code path and test evidence. The levels below are copied from its summary as written.
How to read the levels
Section titled “How to read the levels”There are five levels. Each one is defined by the strongest evidence that exists, not by intent.
| Level | What it means |
|---|---|
| Planned | No code in this build. |
| Implemented | Code exists, but its tests are unit or component tests only, or its end-to-end test cannot run at this revision. A piece was exercised in isolation; the whole path was not. |
| Verified locally | At least one test or recorded run drives the real path end to end against local fixtures or real local tools (a fixture HTTP server, a kind cluster, the real Terraform CLI, PostgreSQL, Docker) and checks the outcome. |
| Verified with a connected provider | A recorded run against a real external account. Nothing in the repository has reached this level. |
| Operated in a pilot | Used for real work in a pilot. Nothing has reached this level. |
Three rules explain the table that follows:
- An area takes its lowest built level. Each area is made of capability families. An area shows the lowest level that any of its built families has reached. Planned families are listed but do not pull the area down.
- “Implemented” often means one part is holding the area back. In most implemented areas the main path is verified locally, and one family lacks an end-to-end run. The right-hand column says which.
- Verified locally is not verified live. Local fixtures establish that Polo follows its contracts. They do not establish compatibility with a live cloud account or the quality of a particular model. Most end-to-end tests use a scripted model.
In the app, the fourth level is labelled “Verified with a provider”.
Summary
Section titled “Summary”| Level | Areas (of 28) |
|---|---|
| Planned | 1 |
| Implemented | 15 |
| Verified locally | 12 |
| Verified with a connected provider | 0 |
| Operated in a pilot | 0 |
The 28 areas
Section titled “The 28 areas”| # | Area | Level | What works today |
|---|---|---|---|
| 01 | Company and environment understanding | Verified locally | Reads pinned repository snapshots, team knowledge, the service catalog and granted MCP tools. The catalog is entered by people; automatic discovery of accounts and dependencies is planned. |
| 02 | Infrastructure as code | Implemented | Plans and applies Terraform through a runner, with approval bound to the saved plan, and authors and validates Terraform offline; both verified locally. The offline plan check and CloudFormation (describe, drift, plan, apply) have no end-to-end run. OpenTofu and Pulumi are planned. |
| 03 | Cloud operations | Verified locally | Reads inventory and cost on AWS, Azure and Google Cloud. After approval, starts, stops or restarts one virtual machine, and changes the size of an EC2 or Compute Engine instance of a connected account. Scaling, tags, snapshots, storage and load balancer changes are planned. |
| 04 | Kubernetes | Implemented | Diagnoses workloads (status, events, logs) and deploys or rolls back a Helm release to the exact prior manifest; both verified locally on a kind cluster. Manifest and config checks have component tests only. Cluster provisioning, RBAC and scaling changes are planned. |
| 05 | Containers and registries | Implemented | Builds an image and publishes it by exact digest, verified locally. Image scanning and Dockerfile lint have no end-to-end run. Signing and provenance are planned. |
| 06 | CI/CD | Implemented | Reads GitHub Actions runs, jobs and logs, dispatches a workflow after approval, follows CI on its own pull request, measures a pipeline baseline and lints workflow files; all verified locally. Repair commits on its own draft pull request and the CI reliability read are implemented only. |
| 07 | Releases and deployments | Verified locally | Marks its draft pull request ready and merges the exact reviewed head after approval; deploys and rolls back Helm releases. Canary and blue-green rollouts are planned. |
| 08 | Repository engineering | Implemented | Reads and edits source in a sandbox, runs Python tests and ShellCheck, lints workflows and opens a draft pull request of the verified change after approval; all verified locally. Node and Go test checks have component tests only. |
| 09 | Observability | Implemented | Queries Prometheus or Grafana metrics and receives Grafana alerts; both verified locally. Loki logs and Tempo traces are implemented only. Dashboards, collectors and alert rules are planned. |
| 10 | Uptime and reliability | Verified locally | Probes public HTTPS endpoints, tracks availability, opens an investigation after consecutive failures and reads a stability window before claiming recovery. Error budgets over time and multi-step synthetic checks are planned. |
| 11 | Incident response | Implemented | Opens investigations from Grafana alerts, Slack alert messages and failing monitors, and investigates unattended with read-only grants; verified locally. One exact remediation inside an incident and the Incidents page are implemented, tested with scripted models and fixtures, not run live. |
| 12 | Performance and capacity | Verified locally | Reads CI timing evidence, measures a pipeline against a baseline and queries metrics. Load tests, capacity forecasts and scaling-policy changes are planned. |
| 13 | Networking | Implemented | Checks HTTP status and TLS for registered public HTTPS origins, verified locally. The DNS read is implemented only. VPC, firewall, routing and load balancer changes are planned. |
| 14 | Certificates and domains | Implemented | Inspects certificates, the trust chain and expiry, verified locally. The DNS read is implemented only. Certificate renewals and DNS record changes are planned. |
| 15 | Identity and secrets | Verified locally | Reads AWS Secrets Manager metadata, never values, and rotates a secret after approval, confirming the new version. IAM roles, workload identities and other vaults are planned. |
| 16 | Security | Implemented | Runs ShellCheck, edits source, opens draft pull requests and publishes images by digest; verified locally. Image scanning, Dockerfile lint, identifier masking and the rules on what is sent to a model are implemented only. Infrastructure and dependency scanning are planned. |
| 17 | Databases | Verified locally | On PostgreSQL: runs approved named queries, takes backups, restores into a verification database or an empty target, and plans and applies additive migrations after approval. Slow-query analysis, replication monitoring and provisioning are planned. |
| 18 | Backups and recovery | Implemented | PostgreSQL backups and verification restores with schema, constraint and row-digest checks, verified locally. The scheduled restore drill has no test or run. Failover rehearsal is planned. |
| 19 | Servers and operating systems | Planned | Nothing is built. |
| 20 | Platform engineering | Implemented | Reads environments, services, owners and deployment targets from the service catalog, verified locally. Starter scaffolds exist as code, but no agent tool reaches them. Service templates and preview environments are planned. |
| 21 | Developer experience | Implemented | Reads and edits source and runs repository checks, verified locally. Starter scaffolds exist as code, but no agent tool reaches them. Onboarding automation is planned. |
| 22 | Cost management | Implemented | Reads tagged cost on AWS, Azure and Google Cloud and publishes reports; verified locally. Whole-account reads and the AWS savings reads (rightsizing, idle resources, anomalies, commitments) have component tests only. Rightsizing and cleanup as approved changes are planned. |
| 23 | Environment lifecycle | Verified locally | Reads the service catalog and plans and applies Terraform for an environment. Temporary environments, scheduled cleanup and decommissioning are planned. |
| 24 | Maintenance and upgrades | Implemented | Edits source, runs repository checks and lints workflows, verified locally. Node and Go test checks have component tests only. Cluster, runtime and database upgrades are planned. |
| 25 | Automation and integrations | Verified locally | Uses granted MCP tools, runs recurring tasks on a schedule, runs uptime monitors, and takes assignments from Slack, Google Chat, Gmail, Jira and ClickUp. |
| 26 | Team collaboration | Implemented | Takes assignments and posts progress in Slack and Google Chat threads, reads and comments on Jira and ClickUp tickets, asks questions and resumes on the answer, reads the team directory, and schedules or joins meetings after approval; verified locally. The Gmail drafts read has no test of the agent path. Outlook mail and Microsoft Teams are planned. |
| 27 | Documentation and knowledge | Verified locally | Searches team knowledge, publishes task reports that cite their evidence, and reads, creates and replaces its Google Docs and Slides after approval. Facts an agent records from a task are implemented only. Diagrams and postmortem drafts are planned. |
| 28 | Engineering planning | Verified locally | Plans with acceptance criteria, delegates specialists within a budget, reviews the evidence, and turns a finished task into a follow-up. Verified with scripted models and with live runs on one local model. Resource and cost estimates for a plan are planned. |
The largest gaps
Section titled “The largest gaps”docs/CAPABILITIES.md names these itself, and they are worth knowing before you rely on an area:
- No live provider evidence. No family has run against a real AWS, Azure, Google Cloud, GitHub, Slack, Google, Microsoft, Jira, ClickUp, Grafana or Kubernetes account in a recorded test.
- Some verified-locally tests do not run in CI. Tests that need a kind cluster, the engineering toolchain image, BuildKit or a real model are skipped in CI and were run by hand. See Testing.
- Some built code has no way in. The starter scaffolds are not reachable from any agent tool.
Maturity is not the same as connected
Section titled “Maturity is not the same as connected”An area can be verified locally and still do nothing in your workspace, because it needs a connection you have not made. The app shows the two side by side: the area’s maturity, and your workspace’s connection state for it (Connected, Registered, Set up, Paused, Needs a connection). Those words are defined on States.
Where to go next
Section titled “Where to go next”- States for the connection and maturity words.
- Connections for setting up what an area needs.
- Testing for how evidence is produced.