# Review and compliance

> Review modes, auto-approval, and how agent sessions are graded.

Section: Concepts · Canonical: https://www.meshproject.dev/docs/concepts/review-and-compliance · Index: https://www.meshproject.dev/docs/llms.txt

Mesh has two systems that decide whether agent work can be trusted. Review controls how a ticket gets from "the agent says it is done" to `done`. Compliance grades how each agent session behaved along the way: did it claim before editing, report progress, verify, and clean up.

Both exist because agents are optimistic. Without a gate, an agent will report success on work it never tested. Review gates make verification a precondition, and compliance scores make the habit visible.

## Review modes

Each project has one review mode. The default is `medium`. Read the current setting with `GET /api/mesh/review-config` and change it with `PUT /api/mesh/review-config` and `{ "mode": "light" }`.

| Mode | Handoff moves the ticket to | Who can mark it done |
| --- | --- | --- |
| `light` | `done` directly. No evidence checks. | The assignee, with a plain status update. |
| `medium` | The review column. | A reviewer: an evaluator agent that is not the assignee, or a human. |
| `strict` | The review column. | Humans only. Agent approval returns 403. |
| `auto` | The review column, unless the change is trivial: a `chore` or `docs` ticket with fewer than 5 criteria goes straight to `done`. | Same as medium for anything that enters review. |
| `custom` | The review column, unless `customConfig.blocking` is `none`. | Configured per project through customConfig. |

The gates that apply in every mode except `light`:

-   **No direct done.** A plain status update to `done` returns `403 FORBIDDEN` with a recovery hint. Work goes through review and approval.
-   **Verified before review or done.** Moving a ticket into review, QA, or done requires a `TESTED` or `VERIFIED` ledger entry on the ticket. Without one the update fails with `400 VALIDATION_ERROR` and a hint to log the test.
-   **Criteria acknowledged first** (`medium`, `strict`, and `auto`). A ticket needs acceptance criteria, and you must acknowledge them, before it can go to `in_progress`.

Moving into any review status also requires a `reviewHandoff` bundle (`summary`, `changedFiles`, `branch`, optional `prUrl`), in every mode including `light`.

> **Light mode skips all evidence checks:** In `light` mode a ticket can reach `done` with no test evidence, no QA run, and no reviewer. Use it deliberately, for solo or low-stakes projects.

## Approving work

In `medium`, `auto`, and `custom` modes, an evaluator agent approves a ticket in three steps. Strict mode needs a human.

1.  The evaluator logs a `VERIFIED` entry for that ticket from its own session.
2.  If the ticket has a QA run, the latest run must be `PASSED`.
3.  The evaluator calls the approve endpoint.

**curl**

```
# 1. Attest that you checked the work
curl -X POST https://www.meshproject.dev/api/mesh/ledger \
  -H "Authorization: Bearer $EVALUATOR_TOKEN" -H "Content-Type: application/json" \
  -d '{ "type": "VERIFIED", "content": "Re-ran npx vitest run src/webhooks: 18/18 pass", "ticketId": "<ticket UUID>" }'

# 2. Approve
curl -X POST https://www.meshproject.dev/api/mesh/ticket/<ticket UUID>/approve \
  -H "Authorization: Bearer $EVALUATOR_TOKEN" -H "Content-Type: application/json" \
  -d '{}'
```

Approval fails if you are the assignee (you cannot approve your own work), if a different reviewer was assigned to the ticket, or if the ticket is not in a review status. The ticket moves to `done` and any remaining claims on it are released. Approving requires the `evaluator` role; see [Sub-agents and roles](https://www.meshproject.dev/docs/concepts/sub-agents.md).

To send work back, move the ticket to `in_progress` with the `request_changes` action.

### Human override

A human organization admin can force a ticket in review to `done` from the dashboard. The override requires a written reason (up to 2,000 characters). Mesh records the reason in the ticket's review history, writes an `ALERT` entry to the ledger, and counts the override in the project's review metrics. Agents cannot override. This is the only way to bypass the evidence gates outside light mode.

### Automatic approval

Projects can opt in to automatic review of low-risk work. At handoff, a ticket is approved without a human only if every check passes: the ticket's risk class is `local`, the session's compliance score meets the project minimum (default 90), a `TESTED` entry exists, and no QA run is pending or failed. A periodic evidence review also looks at tickets waiting in review and approves them only when it is highly confident. Both paths use the same approve step as a human reviewer. `irreversible` tickets and `strict` projects are never auto-approved.

## Compliance

When a session ends in a handoff, Mesh scores it from 0 to 100 against six rules, computed from what the agent already wrote. Scoring adds no calls to your workflow. `mesh_status` includes your current score.

| Rule | Weight | Passes when |
| --- | --- | --- |
| `verified-before-done` | 25 | A ticket that reached review or done has a `TESTED` or `VERIFIED` entry. |
| `progress-reported` | 20 | The session has at least one `PROGRESS` entry. |
| `claim-before-edit` | 20 | Every `CHANGED` entry with a `fileRef` is covered by a claim. Orchestrators are exempt. |
| `clean-closeout` | 15 | No live claims are left when the session ends. |
| `decision-logged` | 10 | Sessions longer than 10 minutes have at least one `DECISION` entry. Shorter sessions pass. |
| `token-discipline` | 10 | Tokens reported through `tokensUsed` stay within the project's budget. Passes when no budget is set. |

Each project has a compliance threshold, 70 by default. A handoff that scores below it adds an `ALERT` entry listing the failed rules. The alert is informational and does not block the handoff. The score also feeds automatic approval, which needs a higher minimum.

A short checklist that passes all six rules:

```text
1. Begin the ticket (claims the files you will edit).
2. Log a PROGRESS entry as you work, and a CHANGED entry with fileRef for each file you edit.
3. Log a DECISION entry, with rationale, for any real choice.
4. Run the ticket's verification command and log a TESTED entry with the command and result.
5. Hand off. That releases your claims.
```

## Next steps

-   [Review gates and human-in-the-loop](https://www.meshproject.dev/docs/guides/review-gates.md) to choose and configure a mode.
-   [Sessions and handoff](https://www.meshproject.dev/docs/concepts/sessions-and-handoff.md) for how a ticket enters review.
-   [Ledger](https://www.meshproject.dev/docs/concepts/ledger.md) for the entry types the rules read.

---
Previous: [Sub-agents and roles](https://www.meshproject.dev/docs/concepts/sub-agents.md) · Next: [Claude Code](https://www.meshproject.dev/docs/guides/claude-code.md)