Contents

Use

Autonomy and policies

Each repository has a policy that decides how far Akesis may go with a fix. Everyone can see it; engineering leads and above can change it. Open it from Autonomy, then the repository.

Tiers

Tier Name What Akesis does
T0 Suggest Explains the fix on the pull request. Changes nothing.
T1 Draft PR Opens a draft for a person to finish.
T2 Open PR Opens a pull request ready for review. A person merges.
T3 Auto-merge Merges when every gate passes.

New repositories start at T0.

The policy

  • Test suite: absent, detected or verified. With no test suite, the most a repository can reach is T1; detected allows T2; auto-merge needs a verified test suite, meaning someone has confirmed the suite catches regressions.
  • Rules: each rule has a tier and, optionally, severities, file paths and services it applies to (one per line). When a change touches several files, the most restrictive matching rule wins, and files no rule matches get T0.
  • Auto-merge boundaries:
    • Sensitive paths are never auto-merged.
    • Extra files allowed in auto-merge adds files beyond dependency manifests and lockfiles.
    • Maximum diff size counts the lines a person would review. Lockfiles don't count, because one upgrade can add hundreds of generated lines; they have their own ceiling of 10,000 lines.
    • Regression watch: how long after an automatic merge a failing default branch, or a firing monitoring alert, counts as a regression (1 to 168 hours, 24 by default). Shortening it asks for a reason.
    • Coverage floor: with a floor set, Akesis auto-merges only when your CI reports line coverage at or above it for that fix's own commit. Without a report it waits. See Scanners and uploads.

No silent escalation

Any change that widens what Akesis may do (a higher tier, a rule re-scoped, a boundary loosened, the test suite upgraded) lists exactly what widens and saves only with a reason. Anything that widens auto-merge also needs an explicit acknowledgement. Lowering autonomy never asks. Every change is in the audit log with its reason and the policy before and after, and if Slack is connected, every change that widens autonomy is posted as a safety alert.

The gates every auto-merge passes

At T3, Akesis merges only when all of these hold, and none can be switched off:

  1. No emergency stop is active.
  2. The repository's test suite is verified.
  3. The change is a dependency update.
  4. Its provenance is verified: every upgraded package's lockfile entry matches the hashes the registry publishes (npm, Go, Rust, and Python with a lockfile that pins hashes).
  5. All required CI checks passed. Unknown CI is treated as pending, never as passed.
  6. Coverage meets the floor, if one is set.
  7. Only dependency manifests, lockfiles or allowed files are touched.
  8. The diff is within the limit.
  9. No sensitive path is touched.

Some changes can never auto-merge: changes written by an AI model, fixes whose provenance can't be verified (Java and .NET today, Python lockfiles without hashes, and Ruby lockfiles without checksums), and changes to your own application code. Those stop at T2 for a person to review. A gate that fails is named in Akesis's comment on the pull request.

Emergency stop

Stop all autonomy in the header (or on the Autonomy page, for one repository) drops autonomy to suggest-only at once, including merges already approved: Akesis checks the stop again immediately before every merge. Any engineer can stop; resuming is an escalation and needs an engineering lead. Both need a reason and are audited. A banner shows the stop on every page.