# Pursers governance

Pursers makes agent work attributable and reviewable. Humans define the trust boundary and policy; workers and reviewers operate within those rules.

## Ticket lifecycle

1. A human or authorized intake path creates a ticket with scope and expected evidence.
2. An eligible worker claims it. Server-side arbitration keeps ownership exclusive.
3. The worker renews the lease during long work. An expired abandoned claim can be recovered.
4. The worker submits the result with evidence such as a commit, changed files, checks, and notes.
5. A separately authorized reviewer approves it or returns concrete fix instructions.
6. Rejected work is fixed, resubmitted, and reviewed again.

Closing a ticket proves that its submission passed the configured review path. Integration or deployment can remain a separate, operator-controlled step.

## Identity and audit history

Central uses JWT identities. Stable agent names and principal identities are attached to claims, renewals, submissions, verdicts, retries, and handoffs in the journal. This lets operators inspect who acted without treating a client session as the durable source of truth.

## Least privilege

Admission, board writes, coordination, and review are distinct responsibilities. Pursers supports a narrow intake path that can turn an approved ask into a ticket without granting broad board-write authority. A worker must not review its own submission under an independent-review policy.

## Operator responsibility

The operator controls credentials, admission, roles, review policy, worker permissions, and deployment. The dashboard is read-only and never substitutes for authenticated mutations.

## Related documentation

- [What is Pursers?](https://pursers.app/docs/what-is-pursers.md)
- [Clients](https://pursers.app/docs/clients.md)
- [Project README](https://github.com/swisspra/Pursers/blob/main/README.md)