rkitoLenses
Per PR
Average number of Lenses evaluated per design audit.
This page describes the intended design. Its inputs — Lenses applied per audit and the audit count — are already recorded, but nothing computes or displays the per-PR average yet. It doesn't appear on your dashboard yet, and no org currently has a live value for it.
÷ total audits
LPPR has no fixed thresholds. It should grow over time as the org adds Lenses — read it as a trend.
What it signals
LPPR is a depth signal. Where PRE tells you how many PRs were evaluated, LPPR tells you how thoroughly each one was checked.
An LPPR of 1.3 means each PR is, on average, being evaluated against just over one Lens — sparse coverage. An LPPR of 8 means each PR is being evaluated against eight distinct design rules.
LPPR should grow over time as an org adds Lenses. A plateau is the signal to revisit Lens coverage; a decline means Lenses are being deactivated without replacement.
How rkito produces it
Every design audit records how many Lenses it applied. Summed across the org, that is Total Lenses Applied (TLA). LPPR divides TLA by the number of audits to give the average depth of review per PR.
Who this metric is for
A PR evaluated against one Lens has barely been reviewed. LPPR shows whether Lens authoring is keeping up with the architecture the org says it wants enforced.
When LPPR plateaus, the gap is usually in specific entity types or domains. Cross-check with Lenses per Pillar to see which domain needs new rules.
A high DCS on a low LPPR means PRs pass because little is checked. LPPR is the context that keeps a conformance number honest.
How this metric gets misused
Do not chase a higher LPPR for its own sake. A rising LPPR concentrated in one domain means one pillar is getting deeper review while others stay thin. Check that new Lenses are spread across pillars, not piled into one.
LPPR is an average.
A healthy org-wide LPPR can hide entity types that no Lens covers at all. It tells you how deep review is on the PRs that were checked, not which parts of the system were never in scope.
What to do as the trend moves
Step-by-step response playbook for each signal state.
Review depth is growing. Confirm it is growing everywhere, not in one domain.
Navigate to /steerings/lenses and review Lens distribution by pillarId to confirm new Lenses are spread across pillars rather than concentrated in one domain (check LPP balance).
No action required. Flag any pillar that has received no new Lenses in the growth period.
Lens coverage has stopped deepening. Find the entity types no Lens touches.
Navigate to /elements and review which system and component types exist, then cross-reference with /steerings/lenses to identify entity types with no Lens coverage. Not yet in rkito: a Lens coverage heatmap showing which entity types, components or systems lack coverage — today this cross-check is manual.
Commission new Lenses for the uncovered entity types and assign them to the relevant pillar owner.
The org is evaluating less, not more. Find out which Lenses were switched off.
Navigate to /steerings/lenses and filter by INACTIVE status to identify recently deactivated Lenses. Cross-check /changecontrols/designaudits to confirm whether audit scope has narrowed.
Investigate the root cause. Lenses being deactivated without replacement means the org is evaluating less, not more — require a CHI for any Lens deactivation.
The numerator of LPPR: every Lens evaluation across the org's audit history.
Where LPPR measures depth per PR, LPP measures depth per domain — use it to check new Lenses are balanced.
The count of active Lenses. LPPR can only grow as fast as GD does.
What is your org's LPPR?
rkito already records the Lenses applied on every design audit. Connect your repo and start building the history LPPR is calculated from.