Skip to main content

Application actions

GAP specifies the lifecycle steps, not the tools that carry them out. What people and AI agents actually do, such as clicking Save, calling a tool, or pressing Publish, is an application action, and each application decides which steps its actions perform. One action can carry out one step, several steps, or none, but every step it performs must meet GAP's rules and keep the content connected to its context.

Three domains, three groupings​

The GAP project models three domains so far: a blog website, issue tracking, and research publishing. Each has a demo application, run locally on made-up data, that tests the draft and shows where the specification needs more work. All three follow the same lifecycle steps but group them into actions differently:

  • In the blog website, each decision is its own action. Setting up the content model proposes a profile and ratifies it, once. A writer's Save creates a version. An editor's Approve or Reject records an approval or rejection and releases nothing. Publish then authorizes the approved version and releases it in one action.
  • In issue tracking, one action does it all. Saving a ticket creates a version, authorizes it, and releases it, as long as the person or AI agent saving holds release authority. Edits to a working copy perform no step until they are saved.
  • In research publishing, source material, manuscripts, and review reports have separate versions. A peer releases feedback, an editor records a signed approval or rejection of an exact manuscript, and a publisher authorizes and releases it. The manuscript stays unpublished until its revisions and source correction are complete. Checking sources performs no step.

In all three, reading released content back is the read and verify step. Previews, working copies, and checks perform no step and record nothing.

The same word can mean different work. In two of the domains, "Save" only creates a version; in the third, it also authorizes and releases it. The name of an action doesn't tell you what happened; the records do.

Combined actions keep every check​

When one action carries out several steps, each step's checks still run. The content is checked against its profile, the actor's permission is checked, and the authorization covers the exact version as it was saved. If any step fails, nothing is released.

An application can offer "Approve and Publish" as one button to a person or AI agent who holds both permissions. It still records the approval and the authorization separately. A release authorization shows who let a version out, not that anyone else reviewed it. A team that wants a separate review on record requires a release approval and decides who may give it.

The same holds when an AI agent calls a tool. What counts is what the application checked and recorded, not what the agent says it did.

Designing your own​

Start with a change that someone will need to understand or check later. What will the receiver need: which version, which sources, whose authorization, what reason? Then decide which actions save that information, who may take them, and where the receiver will find the records. Ask for reasons at the moment someone decides, while they still remember.

The domain guides compare all three domains in detail. The evaluation guide helps plan a trial, and the working draft gives the full rules for grouping steps into actions.