Risk management for your code
A written, enforced and auditable policy for how your code is reviewed.
Not every file carries the same risk. coance lets a team write down which code needs a careful human review and by whom, checks every pull request against that policy, and keeps the record that shows it was followed, including for AI-generated code.
-
Codified
Your risk policy for code lives in coance.yml: which files are critical, how many people must approve them, and whether the author counts. It is version-controlled and reviewed like code, so risk levels are explicit, not tribal knowledge.
-
Enforced
Every pull request is checked against that policy automatically. Each file that needs review gets its own thread, and the coance check stays pending until every file has enough approvals from the right people.
-
Traceable
coance records who approved which file, when and at which commit. When an auditor, a customer’s security review or an incident review asks how a change was reviewed, the answer is on record.
Together they show that your organization has a deliberate, documented strategy for the risk in its code, and the evidence that it works.
The problem
AI tools make changes larger and more frequent. Reviewing every line of every pull request with the same care does not scale, so in practice review gets thinner everywhere, including on the code where a mistake is expensive: payments, access control, personal data, infrastructure, migrations.
GitHub’s CODEOWNERS says who owns a path, not how carefully it must be
reviewed, and a green approval on a pull request does not say which files anyone actually
read. Teams that need to show their review process works, to auditors, customers or
themselves, are left reconstructing it from comments.
The answer is not more review everywhere. It is the right review in the right place: the riskiest code gets the most careful human attention, the rest moves quickly, and there is proof of which was which.
How it works
-
Declare review levels
Define your own levels in coance.yml, strictest first: what a reviewer must do, how many approvals a file needs, and whether the author counts. Map paths to levels in coance.yml or with annotations in CODEOWNERS.
-
A thread per file
When a pull request opens or updates, coance matches every changed file to its level and opens a review thread on each file that needs review, tagging the owners who may approve it.
-
Approve file by file
Reviewers approve a file by resolving its thread or replying /approve. A new commit to an approved file clears its approvals, so nothing changes after sign-off unseen.
-
One clear check
A summary comment shows progress, and the coance status check passes only when every file that needs review has enough approvals from eligible people.
The policy in one file
This policy sends payments, authentication, migrations and the policy file itself to a
critical level with two approvers, neither of them the author, and gives the rest of
/src/ an ordinary review. Files that match no rule need no review. When
several levels match a file, the strictest wins, so moving a rule can never quietly loosen
review.
coance reads the policy from the pull request’s base branch, so a pull request cannot change the rules that apply to itself.
# .github/coance.yml
levels:
critical:
approvals: 2
self_review: false
description: |
Money, access or data that is hard to undo. Read
every changed line; two reviewers, neither of them
the author.
standard:
description: Read the file. Does the change make sense?
rules:
paths:
critical:
/src/payments/: '@acme/payments @acme/security'
/src/auth/: '@acme/security'
/db/migrations/: '@acme/data @acme/security'
/.github/coance.yml: '@acme/security @acme/leads'
standard: ['/src/']
Use cases
Payments
Card-data code reviewed by two people, neither of them the author.
Health data
Code that handles protected health information owned by privacy and security.
Auth and cryptography
Every change to who gets in approved by the security team.
Infrastructure and CI/CD
Terraform, workflows and the review policy itself under the strictest level.
Database migrations
Changes to production data reviewed by people who know it.
Generated code
Generated and vendored files left out, so reviewers see the real change.
Regulatory context
Few rules require line-by-line review. What laws and standards in regulated sectors ask for is closer to this: decide where the risk is, put controls on it, and be able to show they worked. PCI DSS asks for custom software to be reviewed before release, by someone other than the author when reviews are manual. [1] NIST’s Secure Software Development Framework leaves it to the organization to decide where code review is used. [2] In the EU, DORA asks financial entities for documented change management in which changes are recorded, assessed and approved in a controlled manner. [5]
coance helps you demonstrate a documented, enforced and auditable review process. It does not make you compliant with any of these, and this is not legal advice. More context and sources →
Know your code’s liability
On every run coance measures how much code your repository carries and how much of it is governed: total lines of code, lines under each review level, and the lines each pull request changes, in total and per level. The app charts them over time.