Approval workflow

Proposed → pending approval → approved → executing → completed or failed. A proposal can be rejected while it is proposed or pending, and cancelled before it runs if the action is reversible.

The person who requested an action can never approve it. The steward is never an approver.

Only a short, fixed list of actions can be executed by the app: change a milestone, risk, issue or work item status, change a milestone due date, create a work item, and change project health. Each runs through a fixed server-side handler. The app never runs code, SQL, links or tool names supplied by anyone, including the AI.

Immediately before execution the server re-checks who you are, your organisation and role, that the target still exists in the project, that the approval is valid, and that the target has not changed since it was proposed. If anything differs, nothing is applied and the action is marked Failed with a reason. An action is only ever marked Completed if it really was applied.

Changing project health needs a second authorised person, other than the requester and the approver, to confirm before it can run.

Sending emails to stakeholders, academic submission, grading, publication and changes to official records are never performed by the app. Approving them records authorisation only. A person carries the action out elsewhere and then records what they did; that note is stored as an attestation.

Executing an action twice does nothing the second time and returns the original result.