Governance — governed activities
Governance puts consequential actions — a production deployment, granting access, installing a package — behind an explicit, auditable chain: propose → review → gate → sign → execute. An agent or a person proposes, a role reviews the proposal against written criteria, durable gates check that the conditions hold, a human signs, and only then does a separate identity carry the action out. People keep read-only access to production; the act is performed by the identity the standard names, never by whoever asked.
It is built for organisations that let AI agents and automation do real work on their platform and need every such action to be reviewable, signed and traceable — without a person clicking through each step by hand.
Key concepts
- Standard (
Governance/Standard) — an activity type, written in C# with a fluent builder. It declares the required inputs, the review criteria, the gates, exactly one executor, the identity the executor runs as, and the authority: who may propose, who reviews, who signs, and who the maintainer is. A standard is refused at build time if it has no executor, a signature gate without signers, or two gates with the same id. - Activity (
Governance/Activity) — one proposal and everything that happened to it: the review verdict, the gates and their evidence, the signatures, the execution and a log. - Proposal intake (
Governance/Proposal) — how anyone files a proposal. The standard decides whether the proposer is admitted; if so, the activity is filed on the proposer's behalf and the proposer gets read access to follow it. The intake carries inputs only — a state, gates, signatures or a verdict cannot be smuggled in.
Gates
A gate is a condition that is re-checked on every change and on a schedule until it is green:
- Signatures — a number of signers named by the standard. A signature is bound to the inputs as they stand, so editing an input after signing lapses the signature: what was signed is what runs. Signatures also expire after the standard's maximum age.
- External signature — the signer signs in an e-signature provider through the Signature package, at a minimum level (simple, advanced or qualified), and the gate turns green when the request is signed.
- Checks — the CI checks on a repository reference are green.
- No open issues — no open issue on a repository, optionally only those with a given label, such as an outage label.
- No open pull requests — no open pull request on a repository at all; this gate takes no label, so any open pull request keeps it red.
- Window — the action may only run inside a time window.
- Manual — a named signer answers it explicitly, green or waived, with a note.
The life of an activity
| State | Meaning |
|---|---|
| Proposed | Validated; waiting for the review verdict if the standard has review criteria. |
| Rejected / Refused | A missing input, a rejected review, or a proposal the standard does not allow — the reason is written on the activity. |
| Gating | Accepted; the gates are armed and re-judged until all are green. |
| Ready | Every gate green; the signatures are consumed. |
| Executing → Done / Failed | The executor runs under the standard's identity; a failure is handed to triage. |
Nobody approves their own proposal — the one exception is the declared maintainer, and that self-approval is named in the log and on the activity. A reviewer or signer needs no write access to the activity: the platform checks the person against the standard and records the act under their name.
Typical workflow
- Propose — from a standard's page with the Propose button, through an agent that follows the propose skill, or by creating a proposal intake.
- Review — an eligible reviewer accepts or rejects on the activity page.
- Sign — signers press Sign on the activity, or review and sign many activities at once from the approvals inbox.
- Follow — the activity page updates live as gates turn green, signatures land and the executor reports back.
What you get
- The Standard, Activity and Proposal node types with their pages and in-mesh tests.
- A library of seed standards to use and adapt, in two kinds:
- Executable standards, whose executor performs the action once the activity is signed — among them deployment rolls and restarts, access grants and policy changes, package provisioning and removal, enrolment in a package, and group creation.
- Record-only standards, whose executor records the signed decision and performs nothing — among them mail replies, external mail, calendar bookings and cancellations, and dependency merges. Signing one of these sends no mail, books no meeting and merges nothing; it leaves the approved decision on the record until an executor for that action exists. Running an action under the proposer's own identity is not supported yet either: such an execution is refused.
- Agents that propose and review, and skills for proposing and following activities.
- Installing several packages under one review and signature round instead of one activity per package.
The operator's manual is the Guide; the architecture is on Design.