Review and compliance

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

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.

#Approving work

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

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

# 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.

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 to choose and configure a mode.
Sessions and handoff for how a ticket enters review.
Ledger for the entry types the rules read.