The PACT Standard — Part 0: The Standard

The PACT Standard, v1.0 — Prevention · Assertion · Coverage · Trust — authored by Scott Fielder (published 2026-07-09 as the iii OCMAS Standard; named PACT 2026-07-14 — see NAMING.md). A portable, use-case-agnostic specification for building Organization-Centered Multi-Agent Systems whose autonomy is governed, provable, and alive — delivering verified outcomes — rather than performed — sensing, deciding, logging, and shipping nothing.

This document is the normative core. Every other part of the standard elaborates something stated here.

0.1 What PACT is — and the OCMAS lineage

PACT (Prevention · Assertion · Coverage · Trust) is this standard’s name; the letters are its Three Laws (§0.3) and their payoff. OCMAS is the formalism it implements: an Organization-Centered Multi-Agent System designs the organization first and treats the agent as a replaceable occupant of a role. The lineage is Ferber & Gutknecht’s Agent/Group/Role (AGR) formalism; the modern move is to take it literally in an LLM world:

The organization is the product. Roles, charters, authority, schedules, and accountability are the durable assets.
The agent is a commodity. The occupant of a role — an LLM, a deterministic function, or a human — is swappable configuration.
The governance is the trust. What a business can buy is not “an agent”; it is earned, bounded, revocable, provable autonomy — and every one of those four words must be a database fact, not a sentence in a prompt.

0.2 The failure mode this standard exists to prevent

Performed autonomy is the LLM-specific disease. Symbolic agents couldn’t produce convincing motion; an LLM organization generates fluent decisions, plausible rationales, professional drafts, and satisfied log lines whether or not anything ships. The persuasiveness of the intermediate artifacts masks the absence of terminal actuation.

This is not hypothetical. The reference implementation of this standard was audited three times:

2026-07-02: architecture excellent; 9 event producers, 2 consumers; 0 enrollments ever, 0 decision grades ever, predictions hardcoded to zero. Fully flatlined.
2026-07-07: real delivery had begun (60 sends, 283 enrollments) — but the governance around it was performed: the ownership gate had fired once in system history and was bypassed at every delivery edge; 0 of 321 “measured” decisions had ever been graded; the append-only record wasn’t append-only. The failure mode migrated from “does nothing” to “does real work while performing governance around it” — a subtler flatline that survives every “does the table have rows?” check.
2026-07-13: the first documented revival. After the structural cures landed, a live audit recorded a persisted ALIVE verdict for one brand — a full governed trace re-derivable by ID, with the ownership gate participating (routing an unowned lever cross-domain to its owner) rather than bypassed. Recorded with its caveats attached: one brand of eight, UNCOVERED (the roster on day one), grades pending their horizon. The recovery was proven by the same instrument that had twice proven the failure — which is the point of the instrument.

The standard therefore specifies not just what to build (Parts 1–8), but how to prove it is alive (Part 9), the specific ways it fails while looking correct (Part 10), and how to operate it as a service for others (Part 13).

0.3 The Three Laws (build all three or build none)

Every mechanism in this standard descends from three laws. Each closes a blindness the previous one leaves open.

Law 1 — Assert the actions in the substrate

Rules that live only in a prompt are not enforced; they are hoped for. Every norm MUST be a code path, a DB constraint, or a gated registry. An agent literally cannot act outside its charter — prohibitions are prevented by construction, not discouraged by instruction.

Law 2 — Assert the outcomes in the substrate

A unit of work is not “done” until the substrate can verify the outcome exists. Completion is a database fact, not a return value. Law 1 without Law 2 gives you a beautifully governed organization that decides perfectly and ships nothing.

Law 3 — Assert the coverage in the substrate

Laws 1 and 2 prove things about work that happened. They are blind to work that silently never happens. Every responsibility a role owns MUST map to a duty — a declared trigger (time, event, or dependency), an expected outcome, and an SLA — so that silence is detectable per-duty. A role’s job is not a paragraph in a charter; it is a coverage contract the substrate can diff against reality, exactly as a human job description decomposes into a calendar. Laws 1+2 without Law 3 give you an organization that does everything it attempts correctly and attempts a fraction of its job.

Law 3 is new in v1.0. It generalizes the dead-man’s switch from “one weekly meeting” to every declared responsibility of every role, and it is what makes the forward-looking half of the audit possible: the backward audit asks “did outcomes appear?”; the coverage audit asks “did everything that was supposed to happen, happen — and if not, is the reason recorded?” See Part 3: Duty Roster.

Corollary (the pair rule). Every mechanism ships as a pair: writer + reader, publisher + consumer, enforcement at the source + enforcement at the terminal edge, schedule + coverage check. If only one side exists, the mechanism scores L0 — a queue nobody drains, a gate delivery routes around, and a roster nobody diffs are all the same defect.

0.4 The maturity ladder

Every AI program sits somewhere on this curve. Each level is independently shippable.

Level	Name	The bar	You have it when…
L0	Ungoverned	Agents live in prompts. Rules described, not enforced.	You cannot answer “what stops the agent from doing X?” without pointing at a sentence in a prompt.
L1	Logged	Every action is recorded — visible after the fact.	One append-only log captures every AI action with input, output, cost, and outcome.
L2	Gated	Authority regimented; outbound content validated.	An agent literally cannot pull a lever it doesn’t own, and no artifact ships without passing a deterministic gate.
L3	Delivery-verified	”Done” = a verified outcome exists; coverage is declared and diffed.	Your dashboard shows runs completed vs outcomes verified per edge — and duties fired vs duties delivered per role — and they can diverge.
L4	Earned	Autonomy granted per task on evidence — bounded, revocable, self-calibrating.	Task types promote to unattended only after a proven track record, demote on one breach; regulated actions are pinned in code.

Most enterprise agent programs sit at L0–L1. This standard targets L4.

0.5 The ALIVE test and the COVERED test

Maturity scores are advisory. Two binary tests sit on top of them.

ALIVE (Law 1+2 acceptance). In the last 14 days, at least one complete governed action exists end-to-end, traceable by ID through the record:

event → role deliberates → ownership check → validation gate
  → real terminal side effect → verified outcome row
    → falsifiable prediction → graded on horizon

No trace = FLATLINED, whatever the scores say.

COVERED (Law 3 acceptance). For each active role in the last 7 days: every charter responsibility maps to ≥1 duty; every due duty either produced its asserted outcome or wrote a skipped row with a machine-readable reason; and the duty-delivery ratio (duties that delivered ÷ duties due) is computed and surfaced. Unmapped responsibilities, silent misses, or an uncomputed ratio = UNCOVERED.

A product claiming L3+ MUST pass both.

0.6 Conformance language

The key words MUST, MUST NOT, SHOULD, and MAY are used as in RFC 2119. Conformance is assessed only by the audit instrument in Part 9, under its rules of evidence — notably: ground truth is the database and the code, never the logs’ self-report, and no credit for prompts.

0.7 Domain mapping

The standard is use-case-agnostic. Before applying any part of it, map the five domain terms:

Standard term	GTM example	Engineering example	Legal/compliance example
Tenant	brand	org / repo group	client / matter group
Role	CMO, CRO, outreach agent	CTO, architect, reviewer	managing attorney, drafter
Lever	send_volume, spend_cap	deploy_gate, merge_policy	filing_release, disclosure_policy
Terminal edge	email sent, demo booked	PR merged & deployed	filing submitted
Outcome vocabulary	emails_sent, bookings_made	pr_merged, deploy_verified	filing_accepted

Industry varies; the substrate must not.

0.8 The document set

Part	File	Contents
0	`00-STANDARD.md`	This document — laws, ladder, ALIVE/COVERED, conformance.
1	`01-ORG-MODEL.md`	Core objects: role, occupant, charter, lever, duty, scope. The RACI of a governed org.
2	`02-ROLE-CONTRACT.md`	The six configurable dimensions of an agent: Charter · Prompt · Skills · Tools · Context · Schedule.
3	`03-DUTY-ROSTER.md`	⭐ The coverage contract — schedule-as-data, full-coverage rosters, silence detection.
4	`04-SUBSTRATE.md`	The substrate components and portable schemas.
5	`05-GOVERNED-ACTION.md`	The gauntlet every action runs; the validation gate.
6	`06-ACCOUNTABILITY.md`	Predict → grade → calibrate; falsifiability; grading the graders.
7	`07-AUTONOMY-AND-RESILIENCE.md`	Earned-autonomy tiers; circuit breakers; the three monitors.
8	`08-CONSTITUTION.md`	The human plane: five powers, provenance, sticky locks.
9	`09-AUDIT-INSTRUMENT.md`	The compliance audit: pillars, probes, money query, report format, copy-paste prompt.
10	`10-ANTI-PATTERNS.md`	The nine anti-patterns that survive a surface audit.
11	`11-UI-SURFACES.md`	The ant farm: every screen a governed org must ship.
12	`12-PORTING-GUIDE.md`	Converting any product: checklist, build order, definition of done.
13	`13-GOVERNANCE-AS-A-SERVICE.md`	Operating the standard as a service: engagement model, certification, packaging.
14	`14-PLATFORM-AND-PACKAGING.md`	Product packaging: the two doors, platform anatomy, the two-deployment model, updates.
15	`15-DEVELOPER-INTEGRATION.md`	The developer-facing API contract for Door 2 and custom connectors.
16	`16-REPO-SCANNER.md`	The repo scanner: automated structural audit, governance CI, continuous certification.
—	`SCHEMA.sql`	The consolidated portable schema (all tables in one file).
—	`NAMING.md`	The mark (PACT), naming architecture, certification names, usage rules.
—	`OCMAS_REPORT.md` / `PIONEER_POSITIONING.md`	Research materials (academic paper + publication strategy — OCMAS remains the lineage term here).

0.9 How the standard evolves

The standard is versioned. A change enters only through one of two doors:

An audit finding. Every anti-pattern in Part 10 was discovered by auditing a live system, not invented. New failure modes found in the field become probes, then invariants.
A ported implementation. When a new product implements a part and the mechanism needs generalizing, the generalization is folded back here.

The reference implementation is iii-agent-hub (repo-local companions: docs/GOVERNED_AUTONOMY_BLUEPRINT.md, docs/OCMAS_COMPLIANCE_AUDIT.md, docs/OCMAS_AUDIT_RUNBOOK.md). Where those documents and this standard disagree, this standard wins — they are one product’s snapshot; this is the portable pattern.

The organization is the product. The agent is a commodity. The governance — earned, bounded, covered, provable autonomy — is what a business can trust, price, and defend.