The engineering health score
A 100-point weekly scorecard, graded by Claude from the routine outputs, CI, and the dashboards, from security to QA to whether the org is still building.
Engineering health is one number out of 100. The eng lead owns it. It is read weekly and rolled up monthly, and it rolls the whole operating layer in engineering operations into a single score so we can see at a glance whether security, reliability, quality, and delivery are holding, whether the org is still building the next thing, and catch a slide before it becomes an incident.
Claude computes it, because the inputs already exist: the eight routines post their numbers to Slack every morning, CI records every run, the dashboards hold uptime and incidents, and the roadmap and the lead's research log carry the innovation signals. The score reads those sources, applies the rubric below, and posts the result and the deltas to #t-eng every week. It is a measurement, not a target pulled from the air: every number carries its source and the date it was pulled.
The rubric: 100 points, seven categories
| Category | Points | What it measures |
|---|---|---|
| Innovation and AI-forward engineering | 20 | New projects shipping, AI-forward method, high-reliability practice, cross-repo planning |
| Reliability and SLA | 20 | Uptime, incidents, response, alert health |
| Security | 15 | Open findings, scan status, time to remediate |
| Quality and testing | 15 | CI health, the test suites, escaped bugs |
| Delivery and PR flow | 10 | Throughput, review latency, queue aging |
| Bug backlog | 10 | Open count, aging, time to resolve |
| Maintenance and dependencies | 10 | Tech-debt findings, dependency freshness |
The score is the operating state, not a weekly game you start at 100 and lose points in: 100 means every category is green against its target right now. Each category is scored two ways, and both have to hold. Quant is the number its routine already posts, measured against a target. Qual is the eng lead's one-line read of whether that number reflects real health or is green for the wrong reason. A category is full marks only when the number is green and the read agrees. The source in each table is where Claude reads the number.
First fundamental cap. A Sev 1 open, production down, or a red merge path on a default branch caps the whole score regardless of the categories. Health is not bought with surface area while the core is on fire.
Second fundamental cap. A quarter with no major new project planned or shipping caps the score the same way a Sev 1 does. A platform that only fixes bugs and holds its uptime is not a healthy engineering org with a perfect number; it is a stalled one with a quiet pager, and in the AI era a stalled engineering org is the most dangerous state to be in, not the safest. You cannot buy an A by switching innovation off. This is the cap that keeps the other six categories from being gamed: stability is the floor, not the goal.
Innovation and AI-forward engineering, 20 points
| Signal | Points | Full marks when | Source |
|---|---|---|---|
| New projects shipping | 6 | At least one major new project in active planning or build; the innovation ratio of feature work to keeping-the-lights-on at or above target and trending up, not flat | Changelog monitor, PR monitor, the roadmap |
| AI-forward engineering method | 5 | A new agentic or AI-first method trialed or adopted this period and written down; the team's AI practice advancing, not static | The eng lead's research log, the AI-tooling review |
| High-reliability practice | 4 | Reliability practice advancing against a named external bar; an error-budget policy live and tying shipping pace to the budget left | The reliability review, the SLO and error-budget dashboards |
| Deep cross-repo planning | 5 | Every major project has a written plan naming the repos it crosses, the dependency order between them, and the owner per slice, with skills matched to the work | The project plans, the PR monitor cross-repo view |
Reliability and SLA, 20 points
| Signal | Points | Full marks when | Source |
|---|---|---|---|
| Uptime against the SLA target | 8 | Every covered service at or above its tier target for the week | Status and uptime dashboards |
| Critical incidents | 5 | No Sev 1; Sev 2 inside response and resolution targets | Incident channels, the weekly review |
| SLA first response met | 4 | Every support case answered inside its severity window | Support records |
| Alerting pipeline healthy | 3 | Alerts routing with no silent drops and on-call covered all week | Cluster monitor, the alerting dashboards |
Security, 15 points
| Signal | Points | Full marks when | Source |
|---|---|---|---|
| Open critical or high findings | 6 | No critical open; highs inside their remediation window | Security monitor, the audit tracker |
| Blocking scans clean | 5 | No secret, critical dependency, or critical image finding on a merged change | The security pipeline |
| Time to remediate a critical | 4 | Criticals closed inside the target window | The audit tracker |
Quality and testing, 15 points
| Signal | Points | Full marks when | Source |
|---|---|---|---|
| CI green on the merge path | 5 | Build pipeline passing on the default branches all week | CI history |
| Weekly integration suite | 4 | The Citrus end-to-end run passed | The weekly QA dispatch |
| Weekly browser suite | 3 | The console Playwright run passed | The weekly QA dispatch |
| Escaped bugs | 3 | No new production bug that a test should have caught | Bug routine |
Delivery and PR flow, 10 points
| Signal | Points | Full marks when | Source |
|---|---|---|---|
| Shipping throughput | 4 | Production merges in the healthy range, not stalled | Changelog monitor, PR monitor |
| Review latency | 3 | PRs reviewed inside the target; none waiting on review past the limit | PR monitor |
| Queue aging and discipline | 3 | No stale PR past its age limit; every branch on the right base, none direct to a production branch | PR monitor |
Bug backlog, 10 points
| Signal | Points | Full marks when | Source |
|---|---|---|---|
| Open bug count | 4 | At or below the standing threshold | Bug routine |
| Aging bugs | 3 | Nothing open past its age limit for its severity | Bug routine |
| Mean time to resolve | 3 | Inside the target for the week | Bug routine |
Maintenance and dependencies, 10 points
| Signal | Points | Full marks when | Source |
|---|---|---|---|
| Open maintenance findings | 5 | At or below the standing threshold, none aging out | Maintenance monitor |
| Dependency freshness | 5 | No overdue dependency or security update left sitting | The dependency and security digests |
What the eng lead is measured on
The eng lead owns the whole score, but is not measured on keeping it green by freezing new work. A 95 earned by shipping nothing new is a failing grade for the lead, even when the number reads A, and the second cap exists to make that explicit. The job is to hold the operating floor and keep the org building at the same time, never to trade one for the other.
So the lead is measured on the innovation category directly, not only on the six operating categories:
- Research cadence. The lead reads how AI-first teams and high-reliability teams actually work, and brings new method back into the team. A quarter where the way we build did not change is a quarter the lead stood still.
- Planning depth. Complex projects are broken down across the platform repos before build, with the dependency order mapped and the right engineer matched to each slice. A project that stalls because two engineers blocked on each other is a planning miss, not bad luck.
- Net-new capability shipped. Not merges, not bug fixes: new product the platform could not do before, shipped on a cadence. This is the number the second cap protects.
The bands
| Score | Grade | What it means |
|---|---|---|
| 90 to 100 | A | Healthy. Building and holding. |
| 80 to 89 | B | Minor slippage. Named owner, fixed this week. |
| 70 to 79 | C | A category is failing. It leads the next week's priorities. |
| 60 to 69 | D | Two or more categories failing. Slow new work until it recovers. |
| Below 60 | F | Stop and fix. Reliability, security, or innovation is at risk. |
How a week runs
- The score posts to #t-eng once a week, with the category breakdown, every number's source and pull date, and the change from last week.
- A drop names an owner. A category that lost points gets a person and a date, not a general concern.
- The lowest category sets priorities. The weakest category leads the next week's engineering priorities, the same CROSP list in how we set priorities. Innovation is a category like any other: when it is the weakest, the week's priority is a new project, not another bug sweep.
- The rubric is honest about gaps. A standard that is not met yet shows up as a low category score rather than being quietly dropped. The score tells the truth about where the operating layer is weak, which is the point of measuring it.
This is the weekly read on engineering operations: from security to QA to reliability to whether we are still building, one number we cannot argue with, because it is computed from what actually happened.
Want to work at Intempt? Check out our open positions.