The fraction of agent branches that queried Lens criteria before coding and then produced zero critical violations — the direct measurement of pre-generation constraint satisfaction.
This page describes the intended design. It requires MCP access-log correlation with CDA findings, and MCP access logging doesn't exist yet. It doesn't appear on your dashboard yet, and no org currently has a live value for it.
When agents receive the Lens criteria before coding, what fraction produce code that passes those criteria on the first PR attempt? LSCR is the direct measurement of the pre-generation constraint satisfaction pattern. High LSCR proves that pre-generation Lens exposure reduces rework cycles — the agent that knows the evaluation criteria before coding produces fewer violations than the agent that encounters them at CDA time.
LSCR is the proof-of-value metric for Lens authoring investment. It answers the question that architects face every sprint: are the Lens definitions actually shaping agent output, or are they governance theater that accumulates in the registry but never influences code generation? A high LSCR says the Lenses are operationally active. A low LSCR says they are not — and locates the failure point precisely.
The causal chain LSCR measures: agent calls get_applicable_lenses before the first commit → agent receives constraint definitions in context → agent generates code within those constraints → CDA finds zero critical violations at PR time. Every link in that chain is necessary. LSCR measures whether the final link holds.
Requires MCP access log correlation with CDA findings. Identifies branches where get_applicable_lenses was called before the first commit, then checks whether the final PR had zero critical Lens violations. LSCR is the fraction of those branches that achieved zero critical violations.
LSCR is the proof that Lens authoring work has operational impact. If agents load Lenses and still fail them, the Lens prompts may be too abstract or the agent context insufficient. High LSCR means the Lenses are written actionably enough for generation-time use — not just as post-hoc evaluation criteria. Low LSCR is a signal to revisit Lens prompt structure: less "what to avoid" and more "how to satisfy the constraint while building."
LSCR can be high because Lenses are too easy to pass, not because agents are genuinely conformant. A LSCR of 95% with only INFO-severity Lenses is not evidence of good governance. Check Lens severity distribution — LSCR should be measured against BLOCKER and MAJOR Lenses, not just INFO. A registry full of informational Lenses produces a flattering LSCR number that tells you nothing about architectural conformance quality.
Low LSCR with high MCPCAR is a specific diagnostic signal: agents are loading Lenses but not incorporating the criteria into generation. This is a Lens prompt quality problem, not a context delivery problem. The MCP integration is working — the Lens definitions are reaching the agent. The Lens prompts themselves may need to shift from descriptive (“the boundary must not be crossed”) to prescriptive (“when generating a service call, check whether the target crosses the boundary — if so, introduce an anti-corruption layer here”).
Step-by-step response playbook for each signal state.
Agents are using Lens context effectively. LSCR + high MCPCAR = MCP integration working as intended.
Verify that the Lenses contributing to this score are BLOCKER or MAJOR severity. A high LSCR against only INFO-level Lenses does not constitute governance evidence — it means agents are passing criteria that do not block conformance anyway. Check severity distribution before presenting this number to leadership.
LSCR + high MCPCAR is the strongest signal the rkito system produces for MCP integration ROI. Together they prove that agents are loading design context pre-generation and producing conformant output as a result. Document this pairing for architectural governance reviews.
Review Lens prompts for the Lenses failing most often at CDA time despite being loaded pre-commit.
Identify which specific Lenses are generating the violations. A LSCR miss is almost always concentrated in a small number of Lens definitions — the ones with the most abstract prompts. Rank Lenses by CDA violation frequency among LSCR-eligible branches and start with the highest offenders.
The prompts may be too abstract for agents to act on during generation. Rewrite failing Lens prompts to be prescriptive rather than descriptive — less “what the system should look like” and more “what the agent should do when it encounters this situation while generating code.”
Agents are loading Lenses but not producing conformant output. Two distinct root causes require different fixes.
Check MCPCAR first. If MCPCAR is also low, agents are not consistently loading Lens context before coding — the context load itself is inconsistent. Low LSCR with low MCPCAR is a MCP deployment problem, not a Lens quality problem. Fix MCP integration coverage before diagnosing Lens prompts.
If MCPCAR is high but LSCR is still below 65, agents are loading context but not incorporating the criteria into generation. This is a Lens prompt actionability problem. Audit the Lens prompt library for prompts that describe constraints in architectural terms but provide no generation-time guidance. Each failing Lens needs a rewrite that tells the agent what to do, not just what to avoid.
The leading indicator for LSCR. Low MCPCAR means agents are not loading Lens context before generation — LSCR cannot be high if the context delivery step is unreliable.
The strategic outcome metric. LSCR is the mechanism; AHCR is the result. High LSCR across the agent fleet drives AHCR positive — agents outperforming humans on design conformance.
Measures whether agents query design intent before coding, not just Lens criteria. LSCR and AIFI together confirm that agents are loading both approval context and constraint context pre-generation.
rkito computes LSCR automatically by correlating MCP access logs with CDA findings. Connect your repo and see whether your Lens definitions are shaping agent output before the first commit is written.