Code Ledger · Continuous Design Audit

Every PR audited against intent.

Every pull request triggers a Continuous Design Audit. rkito identifies the applicable design intent, evaluates conformance, explains every violation and blocks unapproved drift before merge.

Continuous Design Audit · Pull requestlenses in scope
LevelLensVerdict
LensPII never leaves the ledger servicePass
LensCard data only through the vault APIPass
LensEvery external call has a timeoutRecord
LensRefund service owns refund stateBlock
Illustrative mock. Not an actual product screen.
What’s in it

Three verdicts, each with a reason.

The audit takes the diff, the Architecture Ledger and your Steering principles.

Pass

The change conforms to the intent in scope.

Record

Approved drift: the change is covered by an approved Change Intention.

Block

Unplanned drift: the PR cannot merge until it is fixed or a CHI is raised.

Explained

Every verdict shows which lenses ran, what triggered them and why.

How it works

From a pull request to a verdict.

01A PR opens

Install the GitHub App once. The webhook is configured for you, with no YAML.

02Intent is identified

rkito finds the lenses and Change Intentions that apply to the changed code.

03Conformance is evaluated

Each lens gives a yes or no outcome against the diff and the Ledger.

04The verdict is explained

Pass, Record or Block, with the lens and the reasoning cited on the PR.

Where it is used

At the PR, before code review.

In the PRA design check on every pull request

The audit runs before the PR reaches code review and blocks unapproved architectural drift before merge.

GitHub App
Reading a verdictReading a CDA audit

How to interpret a blocked PR, verify which lenses ran and fix your code or raise a CHI.

Prepare the ground now. Switch on the gate later.

Starter is free for five members. No credit card.