Get a person's sign-off

Some changes can hurt someone outside the code: removing a field a client reads, letting more people see a record, sending data to a new outside host, or dropping data for good. jadpo check fails on each of them until a person accepts it in an acceptance, a small file that says what was decided and why. A coding agent drafts the file and then stops, because the reason has to come from you. This guide removes a field from an API's output and gets it accepted.

You start from the book catalogue in Build an API, committed to git, with its BookView sending each book's author. You work on a branch, as for any change you would open a pull request for.

Make the change

Take author out of what the API sends:

domains/books/types/book_view.jadpo, changed. Book.author is gone from pick:.

use books/entities { Book }/// A book, as the API sends it.type BookView = Output {    pick: [Book.id, Book.title, Book.added_at]}

domains/books/actions/add_book.jadpo, changed. The author: line is gone.

use books/entities { Book }use books/types { BookView, NewBook }/// Adds a book to the catalogue.action add_book(input: NewBook) -> BookView {    var book: Book = Book.create {        set: {            title: input.title            author: input.author        }    }    return BookView {        id: book.id        title: book.title        added_at: book.added_at    }}

Run jadpo api update, which rewrites the API record. Its diff shows the field gone:

git diff api/

diff --git a/api/main.jadpo_record b/api/main.jadpo_recordindex 7cb91b2..ec32289 100644--- a/api/main.jadpo_record+++ b/api/main.jadpo_record@@ -20,7 +20,6 @@ GET /openapi.json  output BookView     added_at: Instant-    author: Text { min_length: 1, max_length: 100 }     id: Uuid     title: Text { min_length: 1, max_length: 200 }

The check stops for a person

jadpo check

   |21 | output BookView   | ^^^^^^^^^^^^^^^ ApiChange.output_field_removed

jadpo check compares the change with your default branch where this branch left it, and finds a client-facing field removed. That's ApiChange.output_field_removed: any client that reads author would find it gone.

(human) at the end of an error's next: line tells your coding agent to stop and ask you which fix you want, because the choice is yours to make (who can see data, what a setting holds). (agent) means your agent can make the fix itself. Here the choice decides whether your API's clients lose a field: put it back, or accept that it goes.

Draft the acceptance

jadpo acceptance new remove_book_author

Wrote acceptances/20261020T1400_remove_book_author.jadpo    main.BookView.author  ApiChange.output_field_removeddecision: 1 change waits for a person's reason --> acceptances/20261020T1400_remove_book_author.jadpo:1  next: Stop and hand over: a person reads the changes and writes why they are accepted on a `///` line above `acceptance`. (human)

It writes one file listing every change this branch makes that needs a person, each as subject: Kind.change. An agent may run this; then it stops, and jadpo check keeps failing:

  |1 | acceptance {  | ^^^^^^^^^^ no `///` reason above

Write the reason

Only a person writes the /// line above acceptance, saying why the change is safe:

acceptances/20261020T1400_remove_book_author.jadpo:

/// No client reads a book's author: the catalogue pages stopped showing it in version 2.acceptance {    changes: {        main.BookView.author: ApiChange.output_field_removed    }}

jadpo check passes. Commit the acceptance with the change. It counts only in the change that adds it: once merged, it is history, and editing it later is an error.

Who approves it

The pull request is where the decision is reviewed. jadpo new writes a CODEOWNERS file naming acceptances/, api/, access.jadpo_record and network.jadpo_record, for you to put your project's owners after. With your git host's branch protection, an owner's approval of the pull request is what lets an acceptance in, and the host records who gave it. CI runs jadpo check with the whole history, so it judges the acceptances against the same base.

What needs a sign-off

Changes that only add need none: a new route, a new optional input field, a new output field, or tighter policy. The record diffs still show them.

Read more

Acceptances, The public API record, Review and sign-off and the error pages acceptance.missing and acceptance.no_reason.

Not built yet

• jadpo approval, the report of what a branch changes in routes, policy, failures and data for a reviewer to read, isn't built yet. Read the diffs of api/, access.jadpo_record and network.jadpo_record instead.
• Acceptances for a package upgrade plan and for raising a monitoring threshold aren't built yet; they come with the commands that make those changes.