Skip to content

WHAT-PEAC-STANDARDIZES.md

Latest commit

 

History

History
65 lines (41 loc) · 6.44 KB

WHAT-PEAC-STANDARDIZES.md

File metadata and controls

65 lines (41 loc) · 6.44 KB
Raw

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. PEAC does not standardize the control plane, business logic, policy engine, payment rail, identity provider, or orchestration layer around those records.

For the boundary next to each adjacent system, see docs/WHERE-IT-FITS.md.

1. Portable, offline-verifiable signed records for agent, API, MCP, and cross-runtime interactions

PEAC defines a compact JWS (JOSE typ: interaction-record+jwt) that any party with the issuer's public key can verify offline, without a network round-trip to the issuer. The JWS is Ed25519-signed over JCS-canonicalized claims (RFC 8785), with kernel constraints enforced fail-closed at issue and verify time.

Evidence you can point at:

  • The conformance fixture corpus under specs/conformance/ covers positive and negative vectors for the core issue and verify path across the current Wire default.
  • The hello-world quickstart at examples/hello-world/ issues a record and verifies it offline in under a minute using @peac/protocol and @peac/crypto.
  • The JOSE hardening test suite at packages/protocol/__tests__/ enforces the stability-contract rules (no embedded keys, no crit, no zip, Ed25519 only).
  • Cross-language parity: the Go SDK (sdks/go/) emits byte-equivalent JCS output against 22 shared fixtures.

2. Cross-protocol record normalization across MCP, A2A, CLI, lifecycle, x402, paymentauth / MPP, ACP, and runtime-governance ecosystems

PEAC defines a single record shape that composes with the agent, commerce, and runtime ecosystems PEAC integrates with. The adapter and mapping layer translates each ecosystem's native attestations into a Wire record, preserves the upstream artifact verbatim, and never synthesizes semantics the upstream did not claim.

Evidence you can point at:

  • The Adapter Readiness column in docs/COMPATIBILITY_MATRIX.md classifies every Layer-4 surface with a conservative rubric; each row carries an evidence tag pointing at per-mapper conformance fixtures and test suites.
  • Mapper-boundary finality guard: @peac/adapter-core.assertExplicitFinality raises MapperBoundaryError (stable code commerce.finality_synthesis_blocked) when a commerce mapper would synthesize payment finality from non-payment artifacts.
  • Per-protocol profiles under docs/profiles/ and docs/compatibility/ describe the boundary for each ecosystem PEAC integrates with.

3. Portable audit records aligned with EU AI Act Annex IV, NIST AI RMF, and ISO 42001 Clause 8

PEAC records double as audit-trail entries suitable for the interaction-logging requirements of current AI governance frameworks. The signed records preserve what the runtime attested, bind policy and config digests, and survive organizational boundaries — the three properties auditors consistently ask for.

Evidence you can point at:

What PEAC does not standardize

PEAC is the records layer. It defines issuance, carriage, verification, and preservation. It does not define:

  • Decision logic. Auth systems, policy engines, runtime-governance toolkits, and approval systems define the decision. PEAC records what they attested.
  • Enforcement. Runtime control planes define enforcement. PEAC records what was enforced.
  • Execution. Shell runners, task runners, and orchestration engines define execution. The PEAC CLI wrapper may spawn a caller-supplied child process to produce an observation, but PEAC does not choose, schedule, supervise, authorize, or orchestrate command execution.
  • Evaluation. Eval platforms, experiment frameworks, and rubric managers define evaluation. PEAC records eval observations emitted by another system; PEAC does not run evaluations itself.
  • Approval workflows. Approval systems and reviewer queues define approval logic. PEAC records approval observations emitted by another system; PEAC does not route or decide approvals itself.
  • Orchestration. Workflow engines define orchestration. PEAC records workflow observations emitted by another system; PEAC does not orchestrate workflows itself.
  • Payment finality. Payment rails (x402, paymentauth / MPP, ACP, Stripe SPT, card networks) define settlement. PEAC preserves upstream attestations verbatim and blocks finality synthesis at the mapper boundary.
  • Identity or trust scoring. Identity protocols (DIDs, VCs, OAuth) and trust-score / reputation systems (ERC-8004 and derivatives) define those. PEAC accepts iss in https:// or did: form; PEAC does not compute trust.
  • Observability presentation. Observability tooling (Datadog, Grafana, Langfuse, OpenTelemetry collectors) defines visualization. PEAC records are exportable to any observability system via receipt_ref as an OTel span attribute.
  • Managed SaaS operation. PEAC's reference verifier at apps/api/ is self-hostable and tenantless. Multi-tenant hosted operation is a separate product concern.

Full boundary with each adjacent category: docs/WHERE-IT-FITS.md.

Why this scope

Every adjacent category has strong incumbents and active specification work. PEAC defining decision logic, enforcement, execution, settlement, or identity would duplicate work the adjacent systems already do and would lose PEAC's defining property — neutrality. PEAC composes with those systems rather than competing with them: every one of them can export signed proof into PEAC records without PEAC picking favorites.

The result is a protocol with a narrow definition that composes across a wide surface area.