rkitoPRs
Evaluated
Count of design audits triggered by GitHub pull request events.
triggerType ∈ {GITHUB_PR_WEBHOOK,
GITHUB_PR_MANUAL})
PRE is a volume count. It has no fixed thresholds — read it as a trend.
What it signals
PRE measures the breadth of CDA coverage across the development workflow. Every pull request that triggers a design audit — automatically via webhook or manually — is a PR whose architectural conformance was actually checked.
For open-source projects, a high PRE signals that community contributions are being evaluated for architectural conformance, not just code correctness.
A repository that never appears in the audit history is outside the governance boundary. PRE is how you notice.
How rkito produces it
Every design audit records what triggered it. PRE counts the audits triggered by GitHub pull request events — either the CDA webhook firing on a PR, or a PR audit run manually. For OSS projects, PRE is available as a public badge from /oss/:slug.
Who this metric is for
A repository with no audit history is ungoverned by definition. PRE is the first check that CDA is actually wired into the places where architecture changes.
As audit volume grows, more PRs means more opportunities for violations to surface. Read PRE alongside DCS to confirm conformance is holding as coverage expands.
For open-source projects, PRE shows that community pull requests are being evaluated for architectural conformance — not only for passing tests.
How this metric gets misused
PRE is a coverage count, not a conformance score. A large PRE says that many PRs were checked. It says nothing about whether they passed. Always read it with DCS.
Do not compare PRE across orgs as a maturity ranking.
PRE scales with how many pull requests an org opens. What matters is whether it tracks your own PR volume — and whether any active repository is missing from it.
What to do as the trend moves
Step-by-step response playbook for each signal state.
More PRs are being evaluated. Make sure conformance holds as volume grows.
Navigate to /changecontrols/dashboard to confirm DCS is holding as audit volume grows. For OSS projects, surface PRE on /oss/:slug.
Monitor the DCS trend alongside PRE growth, and alert if DCS begins to decline as volume rises.
Audit volume has stopped growing. Confirm every active repository is inside the governance boundary.
Navigate to /changecontrols/designaudits and review whether all expected repositories are contributing audits. Any repo missing from audit history is outside the governance boundary.
Check whether all active repositories have CDA webhooks configured, and add any missing repos to the governance scope.
Fewer PRs are being evaluated. Treat it as a governance coverage regression and diagnose it immediately.
Navigate to /changecontrols/designaudits and filter by triggerType = GITHUB_PR_WEBHOOK to confirm whether webhook-triggered audits have dropped.
Audit webhook configuration across all repositories. A falling PRE is a governance coverage regression that must be diagnosed and resolved immediately.
The pass rate of the audits PRE counts. Read the two together: coverage and conformance.
Lifetime Lens evaluations. If PRE grows but TLA stays flat, Lenses are not scaling with the workload.
How deeply each evaluated PR is checked — the depth to PRE's breadth.
How many of your PRs get evaluated?
rkito counts PRE from your first PR-triggered design audit. Connect your repo and see how much of your workflow is inside the governance boundary.