Automated Code Governance
Every pull request passes through independent review panels before merge. Each panel analyzes the change from a different perspective — security, architecture, cost, compliance — and produces a clear verdict. No PR merges without governance approval.
Multi-panel automated review
When a PR is opened, six review panels run in parallel. Each one examines the change from a different angle, like having a team of senior specialists review every PR.
What gets reviewed
| Panel | What it checks | Runs |
|---|---|---|
| Code Review | Architecture decisions, code quality, test coverage, error handling, performance implications | Every PR |
| Security Review | Injection risks, secrets exposure, authentication gaps, dependency vulnerabilities | Every PR |
| Threat Modeling | Attack surface changes, trust boundary violations, data flow risks | Every PR |
| Cost Analysis | Cloud resource impact, token consumption changes, infrastructure costs | Every PR |
| Data Governance | PII handling, data classification, retention policies, compliance requirements | Every PR |
| Documentation | API docs accuracy, changelog updates, breaking change notices | Every PR |
Clear severity ratings
Each panel produces findings tagged by severity. You know exactly what needs attention and what's just a suggestion.
| Severity | Meaning | Impact on your PR |
|---|---|---|
[CRITICAL] | Security or correctness issue | Blocks merge — must fix before proceeding |
[HIGH] | Significant production risk | Blocks merge — must fix before proceeding |
[MEDIUM] | Notable gap that should be addressed | Non-blocking — recommended fix |
[LOW] | Minor improvement opportunity | Advisory — fix when convenient |
[INFO] | Informational observation | No action needed |
What you see
Each panel produces a clear verdict. You get a plain-language summary, and the full technical details are available on demand.
| Verdict | What it means |
|---|---|
| Approve | This panel found no issues — your change is good to go |
| Request Changes | Issues found that need to be fixed before the PR can merge |
| Block | Critical issue — escalated for your attention, merge prevented |
Confidence scores below 0.70 automatically flag the PR for human review, ensuring that uncertain findings get a second look.
Visible, not intrusive
Governance works like the lock icon on HTTPS — you know it's there, but it doesn't get in your way. Here's what you see at each level:
| What you see | What's happening | When |
|---|---|---|
| 🟢 Green indicator | All panels passed | Always visible |
| Plain-language message | "Your PR was approved" or "Security issue found" | When governance has a result |
/governance command | Full details — all panels, findings, verdicts | Whenever you want to look |
Intent validation — always on
The governance engine is customizable — you can disable individual panels or replace the engine entirely. But the Athena intent loop always runs. It verifies that completed work matches the original request, preventing issues from being closed with incomplete or stub implementations.
This is the non-removable floor. You can change how much governance runs. You cannot have zero governance.
Customize to your needs
Configure governance in your project settings. Enable or disable panels, choose your governance depth, or bring your own engine.
governance:
engine: "default" # "default" | "minimal" | "custom"
panels:
security: true
architecture: true
documentation: false # disable individual panels