# Engineering Quality

> The Engineering Quality category — CI, tests, linting, and documentation practice. Weight: 20% of the inspect.software health index.


**Engineering Quality** measures whether baseline engineering and
documentation practices are in place: continuous integration, automated
tests, lint and formatting discipline, and documentation a newcomer can
actually learn from. These are the practices that make change safe — for
human contributors and, increasingly, for
[AI coding agents](/wiki/ai-readiness).

The category carries **20% of the overall health index**.

## Metrics in this category

| Metric | Weight in category | Weight in overall |
| ------ | ------------------ | ----------------- |
| [Engineering practices](/wiki/engineering-practices) | 60% | 12% |
| [Documentation](/wiki/documentation) | 40% | 8% |

[Engineering practices](/wiki/engineering-practices) is a weighted checklist
of hygiene evidence: CI workflows, a test suite, linter configuration,
pre-commit hooks, and an `.editorconfig`.
[Documentation](/wiki/documentation) measures whether the project explains
itself: README, a documentation directory or site, repository description,
topics, and wiki.

## What this category deliberately measures

The signals are **presence-based**: they confirm the infrastructure exists,
not how good it is. That restraint is intentional — grading test *quality*
or documentation *prose* from the outside would be guesswork presented as
measurement. Presence signals are cheap to verify, hard to argue with, and
already separate disciplined projects from undisciplined ones remarkably
well. Deeper signals (coverage, CI pass rates) are on the
[methodology roadmap](/methodology) and will arrive with a version bump.

## Reading the category value

- A low value here rarely lies: missing CI and missing tests are visible
  facts, not judgement calls.
- A high value means the *scaffolding* of quality is present. It does not
  certify that the code inside is good — see
  [signals, not warranties](/wiki/signals-not-warranties).
- Documentation weighs 40%: a well-tested project that explains nothing to
  newcomers is measurably less adoptable, and the category reflects that.

## Improving Engineering Quality

- Add CI that runs the test suite on every push and pull request — the two
  heaviest components in [engineering practices](/wiki/engineering-practices).
- Commit linter and formatter configuration; add pre-commit hooks and an
  `.editorconfig` for full marks.
- Maintain a real README, a `docs/` directory or documentation site, a
  repository description, and topics — each is an individually weighted
  component of [documentation](/wiki/documentation).

Related: [AI readiness](/wiki/ai-readiness) ·
[the health index](/wiki/health-index)