Skip to main content
Version: v0.15.0

Interoperability

PEAC records can travel across agent, API, MCP, gateway, payment-observation, and runtime-boundary workflows without replacing the systems that produced them. PEAC is the records layer beneath runtime governance, not the runtime governance layer itself.

What PEAC standardizes

PEAC standardizes portable signed interaction records and the verification surfaces around them. It defines how records are issued, carried, verified, and preserved across organizational, vendor, and runtime boundaries.

What PEAC does not standardize

PEAC does not standardize the control plane, business logic, policy engine, payment rail, identity provider, or orchestration layer around those records. Inclusion of an adjacent system below is descriptive and does not imply endorsement, dependency, or support by either project.

Adjacent formats and systems

A PEAC interaction record references or observes an upstream artifact while the upstream system remains responsible for its own runtime behavior, registries, validation, and release status. PEAC signs its own envelope (compact JWS, Ed25519) and canonicalizes references with RFC 8785 JCS and SHA-256.

SystemHow PEAC composesBoundary
AP2 (open_mandate_hash)A PEAC record references an AP2 open-checkout-mandate digest.PEAC records a reference; it does not extend AP2 or replace the mandate mechanism.
ERC-8126 (with ERC-8004 context)A PEAC record references an ERC-8126-aligned attestation artifact.PEAC does not issue, validate, or standardize the attestation.
x402A PEAC record preserves an observation of an x402 payment or settlement response surfaced by a PEAC-owned x402 surface.PEAC does not execute settlement, hold funds, or act as a facilitator.
MCPA PEAC record is carried alongside MCP tool responses through _meta carrier fields.PEAC carries evidence; it does not define the tool protocol.
SCITTA PEAC record (typ: interaction-record+jwt) can be carried as a Signed Statement payload for a SCITT-style transparency log.PEAC does not host a log, issue SCITT receipts, or change its wire-format default.
COSE-Sign1 (design note)An informative design for a future COSE-Sign1 receipt carrier alongside the current compact JWS carrier.No runtime, dependency, or wire-format change today.

Canonical references

The authoritative, source-anchored detail (per-row upstream source, status at last check, PEAC artifact, composition recipe, and boundary) lives in the protocol repository:

Upstream statuses change over time. The matrix records the upstream source and a last-checked timestamp for each row, so interoperability claims stay anchored to a verifiable reference rather than a snapshot reproduced here. The matrix is informational; normative requirements remain in the protocol specs/ and docs/specs/ directories.