Pax Equitas

Pax Governance

The organizational intelligence and governance layer.

Pax Governance is the organizational intelligence and governance layer within Pax Equitas. It holds the company's tasks, decisions, authorizations, and evidence; governs what AI agents are authorized to do; records what was executed; and verifies the outcome. It runs no model of its own.

What Pax Governance holds

The record a model does not carry with it.

Four records, written as events happen. The application can only add to them; the database refuses edits and deletions. Together they are the organization's memory of what was decided, who was authorized, what was executed, and what was verified.

Tasks

Units of work with an objective, an owner, and a full event history — never edited — from which the current state is derived.

Decisions

Every founder decision — yes, no, or discuss — with what was asked, why, and what it authorized. Only a person can decide.

Authority

Registered agent identities, each with its own cryptographic key, and the bounded authorizations they hold: one agent, one action, one task, one exact target, one expiry. Revocable.

Evidence

Every check result, every signed change confirmation, every verification, and the release facts the external systems reported — kept beside the decision they belong to.

Pax Governance runs no model and holds no model vendor's credential. The intelligence comes from the frontier models an organization chooses to work with; Pax Governance governs how their work enters the company and keeps the record of it.

How Pax Governance works

Ask. Authorize. Execute. Verify. Record.

Work that Pax Governance oversees moves through the same five steps. One of them can only be taken by a person, and every one of them leaves a record.

  1. 01 · Ask

    Work enters as a task.

    A person or an agent proposes a task with an objective. An agent can propose and report under its own signed identity. It cannot approve anything, including itself.

    Task record · registered agent identities

  2. 02 · Authorize · Human

    A person grants one bounded authorization.

    The decision — yes, no, or discuss — is recorded with what was asked and why. A yes authorizes one registered agent to take one action, for one task, on one exact target, until one expiry. It can be revoked.

    Founder decision record · action authorization · revocation

  3. 03 · Execute

    The external system refuses what is not authorized.

    When a change is proposed or updated, the system where it will land asks Pax Governance whether this agent holds a live authorization for exactly this version. Wrong task, wrong agent, wrong version, revoked, expired: refused. A change accepted after a later revocation is caught at verification, not prevented.

    Required check (GitHub today) · decision record

  4. 04 · Verify

    A separate identity confirms the outcome.

    The independent check gathers evidence from the systems where the work landed — what changed, what went live, what the live system reports — and compares it with the authorization. Pass or fail, every check is written down.

    Separate verification identity · verification records

  5. 05 · Record

    The company keeps the record.

    Every step above was written as it happened: decisions, grants, check results, signed confirmations, verifications. The database refuses any edit or deletion of the governance records, so the history is append-only.

    Append-only records, enforced by the database

Proof point #1

Proven on our own production system.

In October 2026 the loop ran end to end on the Pax Equitas platform itself. An AI agent made one bounded change to production under a company-owned authorization, an external system enforced that authorization, and an independent check recorded the result.

What was proven

  1. 01An AI agent operated under one narrowly limited, company-owned authorization: one task, one action, one exact version of the change, one expiry.
  2. 02GitHub — an external system, not Pax Equitas — enforced the authorization as a required check before the change could land.
  3. 03Unauthorized attempts were refused: no authorization, the wrong task, the wrong agent, a version of the change that was not the authorized one, and a revoked authorization.
  4. 04The correctly authorized change, at exactly the authorized version, was accepted.
  5. 05A person revoked an authorization, and the check refused the change.
  6. 06Evidence of what changed and what went live flowed back into Pax Governance from the external systems, not from the agent's own report.
  7. 07A verification identity separate from the agent checked the outcome, and Pax Governance recorded the task verified and complete.
  8. 08The governance records are append-only, enforced by the database: edits and deletions are refused. Existing records survived the change, and the systems already reporting into Pax Governance kept reporting.
  • No authorizationREFUSED
  • Wrong taskREFUSED
  • Wrong agentREFUSED
  • Wrong version of the changeREFUSED
  • Revoked authorizationREFUSED
  • Authorized agent, exact authorized versionACCEPTED

What it does not establish

  • A distinct account for each agent on the external system. The agent's own signed confirmation binds it to the exact change; account-level identity there is a separate step.
  • Isolation between agents that share one machine.
  • Separation of governance records between customer organizations. Today they hold one organization's records.
  • Governance of every external system. One action class on one system is enforced today; each further system is its own integration.
  • Re-checking authority at the instant a change is accepted. The check runs when a change is proposed or updated; a change accepted after a later revocation or expiry is detected at verification, not prevented.

This is the first proof, not the whole product. This page describes what has run in production and names what has not; nothing here is promised ahead of its evidence.

Where the lines are

Five parts. Hard lines between them.

Intelligence, authority, execution, and verification are different things, held by different parties. Pax Equitas supplies none of the intelligence and all of the organizational layer around it.

  1. 01

    Frontier AI

    Intelligence

    Reasoning, generation, and the capability to execute. It improves on the vendors' schedule, not ours. Pax Equitas builds none of it and competes with none of it.

    Supplied by the model vendors

  2. 02

    Pax Equitas

    The control plane

    Identity and authority, bounded authorization, policy and operational boundaries, institutional memory, execution evidence, and the durable record of the company — the organizational layer a model does not carry with it.

    Owned and operated by Pax Equitas

  3. 03

    Pax Governance

    Governance and institutional memory

    The layer that knows the organization: its tasks, its decisions, who is authorized to do what, what was executed, and what was verified. Pax Governance runs no model. It governs how a model's work enters the company.

    Owned and operated by Pax Equitas

  4. 04

    Agents

    Bounded execution

    AI executors with a registered identity, acting under an authorization limited to one task, one action, one exact target, and one expiry. An agent can ask for authority. It cannot grant it, and it cannot mark its own work verified.

    Vendor runtimes, under identities registered with Pax Equitas

  5. 05

    Verification

    Independent confirmation

    A different identity checks the outcome against evidence from the systems where the work landed — never against the agent's own report — and records every check, pass or fail. An agent can never mark its own work verified; only an independent check or an authorized person can.

    Operated by Pax Equitas, separate from every agent

Use the most capable AI models in the world. Pax Equitas gives them the authority, boundaries, institutional context, verification, and accountability required to operate inside a real organization.

See the loop on real records.

A demo walks a task from proposal to verified completion on the live record — no slide deck.

Request a Demo