Plenty of internal platforms survive on reputation alone. Nobody has audited them in years, the founding engineer left, and half the documented endpoints return errors — yet the slide deck still says “self-service”. This post fixes that with thirteen checks. Run them against any internal platform, score honestly, and you will know within a day whether you are looking at genuine PlatformOps — an internal platform operated like a product — or a museum with a login page. No tools required, no vendor call, just evidence.
How to Run the PlatformOps Audit
Three rules before the checklist. First, judge by evidence, not intention: every check below is either demonstrated or failed, and “we plan to” scores zero. Second, involve one person from a team that merely uses the platform; auditors who built the thing under review will grade their own homework. Third, write the findings down. An audit that produces a score and a date-stamped list of gaps is repeatable; one that produces a meeting is not.
Scope and cadence matter as much as the checks. Audit one platform per half-day; auditing three in a sitting produces three sloppy reports. Run the full set twice a year, and re-run only the previously failed checks in between. And keep the report to a single page — the format is deliberately boring: check, pass or fail, evidence, owner, date. Boring formats survive; clever dashboards get rebuilt every reorganisation and lose their history each time.
Interface Layer: What Users Actually Touch
- 1. The catalog reflects reality. Open the service catalog and pick five entries at random. For each, verify the owner still works there and the component still exists. Catalog pages decay silently, and stale entries are how phantom dependencies survive.
- 2. Declarations match logs. The catalog says who consumes each capability. Pull a week of access logs for one widely used component and count the distinct callers. Where the two lists disagree, you have found either shadow users or stale records — both are findings worth their own ticket.
- 3. A new service starts from a template. Ask how a brand-new service gets created. If the answer involves copying an old repository and deleting things until it runs, template coverage has failed. Templates are where an organisation’s standards stop being tribal knowledge.
- 4. Top tasks succeed unaided. Give a competent newcomer the documentation and ask them to complete the three most common platform tasks — ship a change, request a datastore, read a log. Watch silently. Every interruption is a task-success failure, and the interruptions are the audit’s most useful output.
Core Layer: Where the Authority Lives
- 5. Policy has one enforcement point. Check where rules are actually applied. If guardrails live in documentation, in code review habits, and in three scripts of uncertain age, the core is decorative. A serious platform core applies policy mechanically, in one place, and can show you its decisions.
- 6. Credentials are held centrally. Find where cloud provider credentials live. If they are scattered across pipelines and laptops with varying ages, the trust boundary is fiction. The orchestration core is supposed to be the one component that holds provider access — that is what makes it the trust boundary — and anything holding credentials outside it is a liability with a locker combination taped to the side.
- 7. The golden path is written and staffed. There should exist a documented, supported route from code to production, and someone accountable for keeping it true. Ask who. If the answer is a former team, the path is a ghost.
- 8. Every capability has a lifecycle stage. Each shared component should carry a stage on the standard ladder — running from proposal through alpha and beta to general availability, and onward to deprecation and retirement — together with a date it entered that stage. Components without stages are components without commitments, and their users will discover that during the next incident.
Provider Layer: What Sits Underneath
- 9. Providers are replaceable. Ask what happens if a cloud region, a cluster supplier, or the delivery system must change. A platform assembled in layers — interfaces, core, providers — absorbs that change in one stratum. A platform welded to a single provider rewrites itself. You are checking for seams that allow substitution, not for immunity to change.
- 10. No snowflakes survive beneath the line. Below the platform boundary there will be exceptions; the question is whether they are recorded, owned and counted, or quietly multiplying. Pick the three oldest systems and ask who could rebuild each one if it vanished tonight.
Operating Checks: The PlatformOps Difference
- 11. Service levels are published and examined. A promise nobody inspects is a slogan. Look for stated objectives per capability and a regular review of attainment against them. Where objectives are repeatedly missed without consequence, the catalog is making promises the operation cannot keep.
- 12. Deprecation happens on schedule. List what was retired in the last year and what is scheduled next. A platform that only ever adds capabilities is accumulating debt with interest. The healthiest signal in this whole audit is a visible, staffed retirement calendar — warnings issued, alternatives offered, dates kept.
- 13. Support routes are unambiguous. For any failing capability at any hour, the user should know within thirty seconds who responds. Ambiguity here means every incident begins with archaeology instead of repair.
Scoring Without Flattering Yourself
Count the passes. Ten or more suggests the platform is genuinely operated as a product; seven to nine means the foundations exist but the operating discipline is thinning at the edges; six or fewer means the honest description is “assortment of tools”, and the roadmap should say so. Whatever the score, fight the temptation to repair every gap in a single quarter. Audits earn their keep when the two lowest checks get owners and dates, and the next audit — a quarter out — measures exactly those two.
One caution from experience: do not outsource this to a tool purchase. Every check above can be gamed by buying something, and none of them requires buying anything. The audit measures operating behaviour — ownership, evidence, retirement, support — and behaviour is the part that platforms get judged on by their users, whether or not a scorecard exists.
A final word on honesty. The audit only works if a fail is allowed to be a fail. Teams that start negotiating scores before the report is written have learned the wrong lesson from every audit that came before, and the platform’s users — who live with the reality the scorecard is approximating — can tell.
Three Failure Patterns the Audit Keeps Exposing
Run this across enough organisations and the same three shapes appear. The hollow catalog: checks 1 and 2 fail together, because once records go stale, nobody trusts them enough to update them — the catalog dies of neglect rather than malice. The scattered core: checks 5 and 6 fail together, since credentials end up wherever the last migration left them, and policy fragments to match. And the launch-and-drift platform: checks 11 through 13 fail together after the founding team moves on, leaving promises that nobody remembers making and retirements that nobody remembers scheduling. Each pattern is recoverable, but only when it is named — which is the entire point of writing audit findings down instead of mentioning them.
Who should run it? Not the platform team alone, and not an outside consultant alone either. The pairing that works is one platform engineer plus one user-side engineer, with an agreed half-day budget. The platform engineer knows where the evidence lives; the user-side engineer knows which of it is real.
Where This Checklist Fits Your Growth
If the audit surfaced gaps in your own skills rather than the platform’s, the natural next read is this guide to architecting a career across DevOps, SRE and platform engineering, which maps the competencies each layer demands. And if the template check failed, the fix has a direct analogy in writing work: see how standardized content templates speed up article structuring, then note that the argument applies unchanged to service scaffolding. The full background — definitions, architecture, and the research behind each check above — sits in the Ops Atlas PlatformOps entry, which is the reference this checklist was built from.