# AI Readiness Audit

> What an AI readiness audit actually measures: four dimensions scored on evidence, every finding tagged by how strongly it is supported, and a gap list ranked by what it puts at risk.

Source: https://www.koombea.com/ai-pods/ai-readiness-audit/

---

## 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](https://www.koombea.com/ai-pods/standards/) page covers the full picture.

## How a score is set {#scoring}

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 {#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 {#integrity}

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 {#what-you-get}

- 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](https://www.koombea.com/ai-pods/catalog/compliance-readiness/) and
[test automation](https://www.koombea.com/ai-pods/catalog/test-automation/) Pods are scoped and priced
for exactly this work, and the [standards](https://www.koombea.com/ai-pods/standards/) the audit scores
against are published so you can close them without us.