Peterson
The organizational intelligence and governance layer.
Peterson is the organizational intelligence and governance layer within Pax Equitas. It holds the company's missions, 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 Peterson holds
The record a model does not carry with it.
Four ledgers, written as events happen. The application can only append to them; the database refuses updates and deletes. Together they are the organization's memory of what was decided, who was authorized, what was executed, and what was verified.
Missions
Durable units of work with an objective, an owner, and an event history that is replayed — never edited — to derive the current state.
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 mission, one exact target, one expiry. Revocable.
Evidence
Every gate answer, every merge attestation, every verification check, and the deployment facts the external systems reported — kept beside the decision they belong to.
Peterson runs no model and holds no model vendor's credential. The intelligence comes from the frontier models an organization chooses to work with; Peterson governs how their work enters the company and keeps the record of it.
How Peterson governs work
Ask. Authorize. Execute. Verify. Record.
Work that Peterson governs moves through the same five steps. One of them can only be taken by a person, and every one of them leaves a record.
Proof Mission #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 verifier recorded the result.
What was proven
- 01An AI agent operated under one narrowly scoped, company-owned authorization: one mission, one action, one exact version of the change, one expiry.
- 02GitHub — an external system, not Pax Equitas — enforced the authorization as a required check before the change could land.
- 03Unauthorized attempts were refused: no authorization, the wrong mission, the wrong agent, a version of the change that was not the authorized one, and a revoked authorization.
- 04The correctly authorized change, at exactly the authorized version, was accepted.
- 05A person revoked an authorization, and the gate refused the change.
- 06Evidence of what merged and what deployed flowed back into Peterson from the external systems, not from the agent's own report.
- 07A verifier identity separate from the agent checked the outcome, and Peterson recorded the mission verified and complete.
- 08The governance ledgers are append-only by database trigger: updates, deletes, and truncation are refused. Existing records survived the change, and the systems already reporting into Peterson kept reporting.
- No authorizationREFUSED
- Wrong missionREFUSED
- 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 attestation binds it to the exact change; account-level identity there is a separate step.
- Isolation between agents that share one machine.
- Tenant isolation of the governance ledgers. They are single-tenant today.
- 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 of merge. The check runs when a change is proposed or updated; a merge after a later revocation or expiry is detected by the verifier, 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.
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
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
03
Peterson
Governance and institutional memory
The layer that knows the organization: its missions, its decisions, who is authorized to do what, what was executed, and what was verified. Peterson runs no model. It governs how a model's work enters the company.
Owned and operated by Pax Equitas
04
Agents
Bounded execution
AI executors with a registered identity, acting under an authorization scoped to one mission, 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
05
Verifiers
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 a verifier 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.
Around Peterson
The platform underneath
Command Center, organizations, registry, white-label, partners, deployment, governance, and the developer surface — the eight modules every governed role runs on.
Roles a model can hold
Job descriptions and permission sets a frontier model works inside, each with its honest availability label.
Governance & Trust
What is enforced today, what is disclosed, and who is accountable for it.
See the loop on real ledgers.
A demo walks a mission from proposal to verified completion on the production record — no slide deck.