All Metrics
Agentic Workflow Health · Layer 5

Lens Satisfaction
Before Commit Rate

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.

Target metric — not yet computed

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.

Formula
LSCR = (agent-authored branches that queried
get_applicable_lenses AND had zero
critical Lens violations
÷ agent-authored branches that queried
get_applicable_lenses)
× 100
Range: 0 – 100·Higher is better
Thresholds
≥ 85Agents using Lens context effectivelyTarget state
≥ 65Lens prompts may be too abstractReview prompt actionability
< 65Agents not incorporating Lens criteriaEscalate — diagnose root cause
01

What it signals

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.

02

How rkito produces it

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.

1
01
MCP access log scanned per branch
rkito identifies every agent branch where get_applicable_lenses was called before the first commit timestamp
2
02
Eligible branch pool established
Only branches with a confirmed pre-commit Lens query enter the LSCR denominator — ungoverned branches are excluded
3
03
CDA findings correlated per branch
Final PR CDA results checked for critical Lens violations (BLOCKER or MAJOR severity) on each eligible branch
4
04HIT
Zero critical violations
LSCR hit — agent loaded Lens criteria and produced conformant code
5
05MISS
One or more critical violations
LSCR miss — agent loaded Lens criteria but violated them at generation time
6
06
LSCR = hits ÷ eligible branches × 100
Reported per sprint and trended on org dashboard alongside MCPCAR
03

Who this metric is for

Architect
Design Authority
Proof that Lens authoring has operational impact

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."

04

Watch

Critical misuse to prevent

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”).

05

What to do at each threshold

Step-by-step response playbook for each signal state.

Green≥ 85Confirm & leverage

Agents are using Lens context effectively. LSCR + high MCPCAR = MCP integration working as intended.

01

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.

02

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.

Yellow≥ 65Review prompt quality

Review Lens prompts for the Lenses failing most often at CDA time despite being loaded pre-commit.

01

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.

02

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.”

Red< 65Diagnose root cause

Agents are loading Lenses but not producing conformant output. Two distinct root causes require different fixes.

01

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.

02

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.

Start measuring yours

What is your org's LSCR?

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.