# Review and sign-off

Some changes need a person to accept them before they ship: a change that
can break an API client ([Breaking changes](/docs/the-public-api-record.md#breaking-changes)),
dropping something from the database ([Entities, stores and migrations](/docs/data.md)), a weaker policy
([Policy](/docs/policy.md)), and a new or renamed domain ([Project layout and
modules](/docs/project-layout-and-modules.md)). They all use one form of
acceptance, a file a person writes saying they accept the change
([Acceptances](/docs/acceptances.md)).

`jadpo check` fails until each such change has its acceptance. Acceptances
are files in one folder that your git host protects, with GitHub's code
owners and branch protection or the equivalent, and CI runs `jadpo check`,
which fails without them. So review happens where it already does, on the
git host: Jadpo has no signing or user accounts of its own. `jadpo new`
writes a `CODEOWNERS` listing `acceptances/`, `api/`,
`access.jadpo_record` and `network.jadpo_record`, for the project to put
its owners after; CI checks out the whole history, so the base commit is
there to compare with.

[`jadpo approval --before <ref>`](/docs/commands-for-records-findings-and-review.md#jadpo-approval) writes the report a
reviewer reads: what changed in routes, policy, failures and data, with
each decision that needs a person first. It records nothing: the
acceptance and the owner's approval of the pull request stay the decision.