A green pipeline is not evidence.
An audit that asks a team how they work returns what they believe. This one reads the pipeline, the tests, and the work items, and reports what is actually there. Including when the answer is unflattering.
- Four dimensions, scored zero to three
- Every claim tagged Verified, Inferred, or Blocked
- Exact counts, never extrapolated percentages
Why most readiness assessments miss
Most AI readiness material measures one of two things. Either business strategy, which tells you whether the organization is ready to invest, or code security, which tells you whether generated code introduced a vulnerability.
Both are useful and neither answers the delivery question: if an agent started work in this repository on Monday, would anything catch it when it got something wrong?
That question has a measurable answer. It lives in the pipeline configuration, the observability layers, the traceability between requirements and tests, and how completely the work is described before anyone builds it.
Score your project in about ten minutes
The assessment covers the same four dimensions this page describes and returns a maturity score per dimension. A full audit goes deeper and reads your actual sources.
The four dimensions
Each dimension maps to one published or in-progress standard, so a score is a position against a written bar rather than an opinion.
| Dimension | What it measures |
|---|---|
| Delivery | Whether the pipeline enforces quality before code reaches production: lint, type check, tests, static security scan, dependency audit, coverage threshold, build |
| Observability | Whether the running application can be diagnosed: error tracking, performance monitoring, structured logging, health checks, alert routing, and agent telemetry |
| Validation | Whether test coverage exists across layers for each area of the product, with traceability from each acceptance criterion to a test that proves it |
| Specification | Whether work items carry enough information for an agent to implement them correctly, measured on required fields and completeness tiers |
Eight other systems make up a project, and this audit does not score them. Findings there get noted as context. The twelve systems page covers the full picture.
How a score is set
Each dimension scores zero to three against its standard. The score is not a grade on the team. It is a statement about what a change passes through today.
Gaps are then ranked by consequence, not by how easy they are to fix.
| Severity | What it means |
|---|---|
| Critical | Broken code or a security vulnerability can reach production with no automated check |
| High | A core area is uncovered, or existing tooling is misconfigured enough to be misleading |
| Medium | A missing practice that raises risk but has a workaround |
| Low | An improvement worth making that is not blocking anything |
Where a dimension's standard is still being finalized, gaps are flagged and not counted as failures. The bar is not finished, so scoring against it as though it were would be unfair to the project.
How it runs
Access is verified first. Whatever cannot be reached is recorded as inaccessible, and the missing access becomes a finding in its own right rather than a hole filled with an assumption.
Then evidence is collected per dimension by reading the sources directly. The pipeline configuration, not a description of it. The test suite, not the coverage badge. The work items, not a sample someone selected.
The rules that keep it honest
These govern the auditor, not the project. They are the reason the output is worth acting on.
- Evidence first. A gap is never filled with an inference. If a source cannot be reached, the finding is tagged as blocked and the audit moves on.
- Every claim carries a strength tag. Verified means confirmed by reading the source. Inferred means derived indirectly, and says so. Blocked means the source was unreachable.
- Exact counts over percentages. When all items can be counted, the exact number is reported. When sampling is necessary, the sample size is stated and nothing is extrapolated without labelling it.
- Ask before sampling. Reading twenty of a hundred work items is agreed in advance, and sample conclusions are never carried forward as facts once the full set becomes available.
- Classify before writing. Every data point is tagged before a section is drafted, and classifications are never mixed inside one claim.
- Evidence and interpretation stay separate. Raw data lives in evidence files. The report cites them rather than re-embedding them.
- Re-verify on new access. When a blocked source opens up, the affected sections are redone from scratch rather than patched.
- Frame for the reader. The same evidence is emphasized differently for a quality lead than for a delivery lead. The evidence does not change.
What you get back
- A four-row maturity dashboard: dimension, score, what the score is based on, and the finding that mattered most
- A methodology note listing which sources were read and which were unreachable
- A per-dimension comparison of the standard against the current state
- One consolidated gap list, ranked by severity
- Remediation recommendations, when you want them
What this looks like when it goes badly
The reason this audit reads sources instead of asking questions is that the interesting findings are invisible from the inside.
On one project the backend pipeline invoked a test command for a framework the team was not using. It found nothing, ran nothing, and reported green on every merge, while 93 test files sat in the repository and never executed. Everyone involved believed tests were running. The badge said so.
The frontend on the same project had no quality gates at any stage, and none of the five observability layers we look for, with a comment where error reporting should have been.
Neither finding required judgment. Both required looking.
Then what
A gap list is not a plan. If you want the gaps closed, the compliance readiness and test automation Pods are scoped and priced for exactly this work, and the standards the audit scores against are published so you can close them without us.
Bring us the backlog.
In 30 minutes, we will show you what a Pod would ship first and how we would price it.