Formula
LPP = count(Lenses where
statusCode = ACTIVE
AND pillarId = this pillar)Thresholds
Mature coverage
Developing
Shallow coverage
Reading it
A Pillar with one Lens has shallow automated coverage. One evaluation criterion evaluates every PR against a single dimension of design intent. A Pillar with twelve Lenses can evaluate PRs against a rich set of design rules, catching violations across multiple facets of the domain.
LPP indicates how thoroughly a domain's intent has been made machine-readable and enforceable. A Security Pillar with LPP=1 has one security principle in automated enforcement. A Security Pillar with LPP=12 has twelve. These are not equivalent security postures — regardless of what PCR reads.
LPP is the per-pillar complement of GD (Governance Depth). GD measures total active Lenses across all pillars; LPP surfaces whether that coverage is distributed or concentrated. An org with GD=20 and a Security Pillar at LPP=1 has a critical blind spot even though the aggregate count looks healthy.
How rkito produces it
- 01
Count ACTIVE Lenses for this pillar
Query Lenses where statusCode = ACTIVE and pillarId matches the pillar under review
- 02
Navigate for detail
Go to /steerings/lenses and filter by pillarId to see which Lenses contribute to this count
- 03
Each new Lens activated via CHI increments LPP
Lenses become ACTIVE when approved through a Change Intention. Deactivating a Lens decrements LPP.
- 04
LPP is a live count, not a computed rate
Unlike PCR, LPP does not depend on PR volume — a pillar with no recent PRs still has a meaningful LPP
- 05
Read LPP alongside PCR and AFPR
High LPP with high false positive rate (AFPR) signals redundant Lenses rather than genuine coverage breadth
Who reads it
LPP per pillar shows where coverage is thin and where to focus Lens authoring effort. A Security Pillar at LPP=1 is the most urgent authoring priority — not the pillar with the lowest PCR, which may simply reflect a well-covered domain with genuine violations.
How it misleads
What to do at each threshold
Step-by-step response playbook for each signal state.
Mature coverage. Shift focus from authoring new Lenses to verifying quality and eliminating overlap in existing ones.
- Navigate to
/steerings/lenses, sort by pillarId, and compare prompts for semantic overlap. - Redundant Lenses inflate LPP without improving coverage and produce correlated failures that make PDRP look worse than it is. Deprecate duplicates through a Change Intention.
Adequate for early-stage governance. Coverage is sufficient to catch the most obvious violations but misses emerging patterns.
- Review design audit failures quarterly. Each recurring failure pattern that lacks a Lens is an authoring opportunity.
- Expand as audit findings reveal new violation patterns. Do not author Lenses speculatively — ground each new Lens in observed violations.
One evaluation criterion is not meaningful coverage for any domain. This pillar's design intent is almost entirely un-enforced.
- Author at least 3 Lenses for this pillar covering the most common violation patterns. Identify these by reviewing recent design audit failures at
/changecontrols/designaudits. - Book a Lens authoring session with the pillar owner. They hold the domain knowledge required to write effective evaluation criteria.