Lenses per
Pillar
Count of active Lenses with this pillarId.
statusCode = ACTIVE
AND pillarId = this pillar)
What it signals
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
Who this metric is for
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 this metric gets misused
LPP is gameable by authoring overlapping Lenses that evaluate the same property from slightly different angles. High LPP with high AFPR (false positive rate) suggests redundant Lenses rather than genuine coverage breadth.
Redundant Lenses inflate LPP without improving coverage and produce correlated failures that make PDRP look worse than it is. A pillar with LPP=12 where eight of those Lenses evaluate the same boundary from different phrasings is not a well-covered pillar — it is a pillar producing misleading signal volume.
Review Lens prompts manually for semantic overlap when LPP grows rapidly. Navigate to /steerings/lenses, sort by pillarId, and compare prompts side by side. rkito does not currently auto-detect Lens redundancy.
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.
LPP contextualises PCR — PCR=100 with LPP=1 is not strong governance. Always read conformance rate alongside the coverage count that produced it.
GD is the org-level aggregate of all active Lenses. LPP is the per-pillar decomposition that shows whether GD is distributed or concentrated.
A pillar with low LPP and declining PDT is a domain where intent is thin and conformance is falling. LPP tells you why PDT improvement is slow.
How many Lenses does your thinnest pillar have?
rkito computes LPP per pillar automatically from your Steering layer. See which domains are well-covered and which are a single rule away from blind spots.