rkitoTotal Lenses
Applied
Cumulative count of Lens evaluations across all design audits.
across all design audits
TLA is a volume count. It has no fixed thresholds — read it as a trend.
What it signals
TLA is the lifetime governance throughput metric. It answers a simple question: how much automated design review has this organisation done?
Every design audit evaluates a PR against some number of Lenses. TLA adds those evaluations up across the org's entire audit history. It grows with both breadth — more PRs evaluated — and depth — more Lenses applied to each one.
That makes it a useful signal of governance maturity for org profiles and open-source badges: a public, cumulative record that design rules are being applied, not just written down.
How rkito produces it
Each design audit records how many Lenses it applied. TLA is the sum of that count across every audit in the org. It appears as the Lenses Applied tile on the org profile at /orgs/:uid, and as a public badge for OSS projects at /oss/:slug.
Who this metric is for
TLA is the cumulative record of automated design review. Its growth belongs in engineering leadership communications as evidence the governance model is doing work.
Compare TLA growth against PRE growth. If audit volume rises but TLA flattens, Lenses are not scaling with the workload and coverage is thinning.
For open-source projects, TLA is a visible signal that contributions are checked against published design rules — not only against tests.
How this metric gets misused
TLA measures how much checking happened, not how well the code conformed. A large TLA with a falling DCS means a lot of review is finding a lot of problems. Read TLA with DCS, never instead of it.
Do not treat a bigger TLA as better coverage by default.
Because it is cumulative, TLA grows with time and PR volume alone. To see whether each PR is being checked more deeply, look at LPPR. To see whether coverage is spread across domains, look at Lenses per Pillar.
What to do as the trend moves
Step-by-step response playbook for each signal state.
Governance throughput is growing. Make it visible.
Surface TLA on the org profile at /orgs/:uid and on the public OSS page at /oss/:slug as a governance maturity badge.
No action required. Highlight TLA growth in engineering leadership communications.
Lens evaluations have stopped growing. Check whether Lenses are keeping pace with audit volume.
Navigate to /changecontrols/designaudits and compare audit volume (PRE) growth against Lens count growth. If audit volume is growing but TLA is flat, Lenses are not scaling with workload.
Commission new Lenses at /steerings/lenses to expand coverage, and assign them to pillar owners with a 30-day target.
A falling TLA on a growing codebase is a coverage regression.
Navigate to /changecontrols/designaudits and check whether PRE is also falling. A falling TLA on a growing codebase is a coverage regression that needs webhook diagnosis.
Audit CDA webhook configuration across all repositories, and investigate whether any repos were recently removed from governance scope.
Audit volume. Compare its growth with TLA to see whether Lenses are scaling with the workload.
TLA divided by total audits — the average depth of review each PR receives.
The number of active Lenses. More active Lenses is what lets TLA grow faster than PR volume.
What is your org's TLA?
rkito starts counting TLA from your first design audit. Connect your repo and watch your governance throughput build.