The three questions — and where to find the answers
Every blocked PR produces three questions in sequence. rkito's audit detail page answers all three without requiring an architect to be on-call. The answers are in the five-stage Explainability Timeline.
Getting to the audit detail page
When your PR is blocked by the rkito/cda status check, the “Details” link on the GitHub check takes you directly to the audit in rkito. You can also navigate via:
/cdaCDA Dashboard — find the audit in the recent audits list/changecontrols/branchesBranches — click the Design Reviews column for your branch/changecontrols/changeintentions/[uid]If you have a CHI — the Audits tab shows all linked auditsStage 3 — Verify the lens selection
Before reading the check results, confirm that the right lenses evaluated your code. Expand Stage 3 (Lens Matching) in the timeline. You will see two tables.
Each matched lens shows the channel(s) that triggered it.
This section is collapsed by default. Expand it to see every active lens in your org that did not run against this PR, with the reason.
Common reasons: glob patterns did not match any of your changed files; no taxonomy entity overlap between the lens scope and your changed components; lens is component-scoped but the files were not classified to that component.
/steerings/lenses/[uid]) and update its glob patterns or component associations with your architect.Stage 4 — Reading a failed check
Expand Stage 4 (Lens Evaluation). Each lens that ran shows as a block with its check-by-check results. Failed checks are marked with ✗ and are expanded by default when a lens has failures.
Click a failed check row to expand it. You will see two tabs.
Reasoning — the AI's full analysis. Not a summary. The verbatim explanation of why the code did or did not conform to the principle being checked.
Evidence — the specific file and line reference the AI cited when reaching its conclusion.
Metadata — model used, token counts, duration, whether the result was a manual override.
System Prompt — the full instructions given to the AI for this evaluation, including the architectural principle being enforced.
User Prompt — the exact diff content and context the AI saw when answering this question.
Raw Response — the AI's response before parsing. If you believe the AI reached the wrong conclusion, this is where you see exactly what it said and why the parser extracted the answer it did.
If you believe the AI's verdict is incorrect — for example, the reasoning references a line that does not reflect what your code actually does — use the ✦ Ask button on the failed check. Describe what you believe the AI misread. Ask rkito can help you articulate whether this is a false positive and what to do about it.
How to fix a blocked PR
There are two paths to unblocking a PR. Which path is correct depends on whether the code change is a conforming change or a deliberate structural change.
If the check caught a genuine design violation — your code crossed a boundary it should not, used a pattern that is explicitly prohibited, or skipped a required interface — the fix is to change the code.
The AI's reasoning in the failed check explains what the violation is. Use ✦ Ask on the failed check to ask “what would conformant code look like here?” Push the fix to the PR branch — rkito re-evaluates automatically on the next push.
If the code change is correct and the violation is intentional — you are making a deliberate structural change that was agreed to but not yet formally recorded — the fix is a CHI, not a code change.
/changecontrols/changeintentions/newHandling a false positive
A false positive is when the CDA blocks a PR for a violation that is not actually present — the AI misread the diff, misidentified the pattern, or applied a lens to a file that does not belong to the lens's scope.
Open the failed check. Read the reasoning carefully. Open the AI Call tab and read the user prompt — this shows exactly what the AI saw. Identify where the AI misread the situation.
Use ✦ Ask on the failed check. Explain what the AI misread: “The reasoning says X but my code is actually doing Y because Z. Is this a false positive?”
If confirmed as a false positive, escalate to your architect with the specific prompt evaluation UID. The architect can review the lens prompt that produced the false positive and update the prompt wording or scope to prevent recurrence.
In the interim, the architect can apply a manual override on the specific evaluation. Manual overrides are recorded with the reviewer identity and reason, and are visible in the audit trail.
Note: the rkito team tracks false positive rates per lens category. If you identify a systemic false positive pattern in a lens, raise it as a lens quality issue so it can be addressed at the prompt level.