Use PACT as a runtime, not a demo.
The release ships an importable ESM SDK, validated adapters, durable server authority, an HTTP connector, real REST-provider canonical bridges, WebMCP/MCP agent bridges and a machine-readable product manifest. The Helios flow remains only a reference scenario.
import { definePactAdapter } from '/sdk/adapter.js';
import { createPactRuntime } from '/sdk/runtime.js';
const adapter = definePactAdapter({
id: 'acme.flags', version: '1.0.0',
describe: () => ({ name: 'Feature flags' }),
plan: async ({ intent, state }) => ({
effects: [{
path: `flags.${intent.flag}`,
before: state.flags[intent.flag], after: true
}],
invariants: [{ path: 'billing.plan', equals: state.billing.plan }]
}),
verify: async ({ intent, state }) => state.flags[intent.flag] === true
});
const pact = createPactRuntime({
adapter,
initialState,
verifyApproval: async request => verifySignedApproval(request)
});Your adapter supplies the plan. Your application supplies authority.
plan() receives the intent and a cloned canonical state, then returns declarative effects and invariants. PACT rejects mismatched preconditions before approval, binds the exact plan to a SHA-256 digest, checks the canonical version before commit, rechecks invariants after mutation, calls verify(), and emits a receipt.
The generic runtime does not trust a caller-provided boolean. verifyApproval must validate whatever approval artifact your application uses and return at least humanPrincipal and agentSession. Those claims are hashed into the approval lease and included in the verified receipt.
import { createPactAuthority } from '/sdk/authority.js';
const authority = createPactAuthority({
store: durableAtomicStore,
verifyApproval: request => verifySignedApproval(request)
});
const cap = await authority.issue({
approval, txId, planHash, baseVersion, adapter
});
const authorization = await authority.authorizeCommit({
token: cap.token,
txId, planHash, baseVersion,
idempotencyKey
});Make commit authority opaque, bound and single-use.
createPactAuthority() issues opaque short-lived capabilities after an application-controlled approval verifier returns a human principal and agent session. A capability is bound to the transaction ID, exact plan hash and canonical base version. Commit authorization atomically consumes it; only a retry with the same idempotency key can replay the same authorization.
Production integrations must provide a durable atomic store implementing get, create and compare-and-swap semantics. MemoryAuthorityStore is included only for local tests and process-lifetime development; it is not a durable production backend.
import {
createPactRestResourceBridge,
createPactJsonResourceAdapter
} from '/sdk/rest-resource.js';
import { createPactServerRuntime } from '/sdk/server-runtime.js';
const canonical = createPactRestResourceBridge({
store: durableAtomicStore,
key: 'account:42',
baseUrl: 'https://api.example.com',
resourcePath: '/v1/accounts/42',
headers: { authorization: `Bearer ${providerToken}` }
});
const runtime = createPactServerRuntime({
store: durableAtomicStore,
approvalSecret,
releaseSha,
adapter: createPactJsonResourceAdapter({
id: 'example.account', version: '1.0.0'
}),
canonical
});
const intent = {
operations: [
{ path: ['account', 'owner'], value: 'Maya' },
{ path: ['account', 'status'], value: 'suspended' },
{ path: ['access', 'role'], value: 'read' },
{ path: ['access', 'enabled'], value: false }
]
};
const preview = await runtime.service.preview({
adapter: { id: 'example.account', version: '1.0.0' },
intent
});
// One frozen plan → one approval → one provider write → one receipt.Bind a complete business change to the provider's real revision.
The REST-resource adapter accepts a backward-compatible single {path, value} intent or a batch of up to 256 non-overlapping JSON-path replacements. A batch becomes one deterministic multi-effect plan, one human approval capability, one ETag-conditional provider mutation and one verified receipt. Duplicate or ancestor/descendant-overlapping paths are rejected so mutation order cannot change the meaning of the approved plan.
The REST-resource bridge reads the provider's JSON object and ETag, converts that provider revision into PACT's monotonic canonical version, and commits with If-Match plus Idempotency-Key. Out-of-band provider drift makes an earlier approval stale before mutation. A lost provider response can be recovered only when a subsequent read observes the exact intended resource under a new ETag.
Provider credentials stay server-side. The bridge refuses insecure remote HTTP origins, cross-origin resource redirects/configuration and provider responses without an ETag. PACT does not claim exactly-once semantics when a third-party provider ignores conditional writes or idempotency, and batch atomicity is scoped to the provider's single resource mutation rather than falsely claiming a distributed transaction across unrelated providers.
The official /api/pact entrypoint can select this mode using PACT_RUNTIME_MODE=rest-json with PACT_REST_BASE_URL, PACT_REST_RESOURCE_PATH, PACT_REST_RESOURCE_KEY and PACT_REST_ADAPTER_ID. See /docs/rest-provider.md for the full server-only configuration contract.
import { createPactHttpConnector } from '/sdk/http.js';
const api = createPactHttpConnector({
baseUrl: 'https://example.com'
});
const request = new AbortController();
await api.preview({ intent }, { signal: request.signal });
await api.commit({ txId }, txId, { signal: request.signal });
// Caller cancellation => PACT_HTTP_ABORTED
// Connector deadline => PACT_HTTP_TIMEOUT
request.abort();Keep consequential retries idempotent and requests cancellable.
The canonical REST connector posts to /api/pact, enforces HTTPS outside localhost development and requires an idempotency key for commit before network I/O. Every operation accepts an optional caller AbortSignal; caller cancellation fails as PACT_HTTP_ABORTED, while the connector's own deadline remains PACT_HTTP_TIMEOUT, so application code can distinguish user/navigation cancellation from transport timeout.
A production authority endpoint must persist transaction state, replay protection and idempotency records in a durable atomic store. Accept a deployment only when its durable backend, source provenance and live transaction smoke tests are verified. Discover the supported modules, schemas, HTTP envelope and documentation URLs from /pact-manifest.json.
const context = document.modelContext;
const registration = new AbortController();
await context.registerTool({
name: 'pact_inspect',
description: 'Inspect PACT state without mutation.',
inputSchema: { type: 'object', properties: {}, additionalProperties: false },
annotations: { readOnlyHint: true, untrustedContentHint: true },
execute: async input => { /* PACT bridge */ }
}, { signal: registration.signal });
// Abort the registration to unregister the tool.
registration.abort();Page-scoped tools through document.modelContext.
PACT targets the current WebMCP Community Group draft surface, where tools are registered on document.modelContext. The API is experimental and may change; PACT isolates registration behind its WebMCP bridge so integration code does not need to spread draft-specific calls throughout an application.
The current ToolExecuteCallback receives a single input object. The AbortSignal belongs to ModelContextRegisterToolOptions and unregisters the tool when the registration is aborted; the current draft does not define a separate execution-callback abort signal. The tool annotation dictionary exposes readOnlyHint and untrustedContentHint; PACT uses only those WebMCP annotation fields. HTTP and MCP retain their own cancellation mechanisms.
The canonical agent bridge exposes exactly inspect, preview, approve, commit, verify and receipt across HTTP, WebMCP and MCP. Remote provider output is marked untrusted on the WebMCP bridge by default.
Expose only operations valid for the current transaction state.
IDLE → preview. PREVIEWED → authenticated human approval. APPROVED → commit. COMMITTED → verify/recover verification. VERIFIED → receipt.
The reference workspace demonstrates the canonical HTTP lifecycle. Agent integrations can expose the same authority through HTTP, WebMCP or MCP while keeping provider credentials and consequential writes behind the server boundary.