Originary is a production layer for issuing, verifying, and exporting portable signed interaction records for workflows that need to be verified outside your system.

What does Originary create?

Originary creates signed interaction records that bind issuer, timestamp, policy, terms, result, metadata, and signature into a portable artifact.

When do teams need Originary?

Teams need Originary when another party needs proof beyond internal logs for an API, MCP, agent, commerce, or runtime workflow.

Where should we start?

With one workflow where another party needs something stronger than logs.

For APIs, agents, MCP tools, and commerce

Prove what your agents and APIs did.

Q: Is verification tied to Originary?

No. Records are portable, verification can stay independent, and self-hosted paths remain available.

Originary turns API calls, MCP tool use, runtime decisions, and payment events into signed records another party can verify offline.

Built on PEAC Protocol, the open standard for portable signed interaction records.

Start with one workflow Verify a sample record

Offline-verifiableHosted or self-hostedDownloadsNo stack replacementOpen record format

Agent Governance Toolkit

Claude Managed Agents

Works with x402, MCP, MPP, Stripe, A2A, AP2, Cloudflare, Vercel, Visa, Mastercard, OpenAI, OpenTelemetry, LangChain, Microsoft Agent Governance Toolkit, and Claude Managed Agents.

Input event

API callpolicy + result

MCP tool callparams + output

Payment eventterms + access

Runtime decisionapproval + reason

Signed interaction record

Signed record

issuerapi.company.com

timestamp2026-04-24T12:21Z

policy bindingverified

terms digestmatched

result hashsha256:b7f4...91ac

Signaturevalid

Verifier reportVerified

Signaturevalid

Issuerverified

Policymatched

Termsmatched

Recordportable

Problem

Automation crosses boundaries. Your proof usually does not.

Logs, dashboards, screenshots, and CSV exports work while everyone trusts the same system. They break down when a customer, partner, auditor, or another team needs to verify what happened independently.

Originary is for the moment when someone asks: "Can you prove it?"

API result dispute

Prove which policy, terms, and result applied to one API interaction.

Agent action review

Inspect a tool call, runtime decision, or approval after the fact.

Payment or access proof

Bind payment terms, access decisions, and results into a verifiable artifact.

Partner or audit handoff

Export a review-ready record without exposing internal systems.

Built for API platform teams, MCP and agent infrastructure teams, commerce/payment owners, and security or compliance reviewers.

Product

Originary turns important events into records another party can inspect.

Issue

Create a signed record from an API call, MCP tool call, runtime event, or payment flow.

Verify

Check issuer, timestamp, signature, policy binding, terms digest, and result hash independently.

Export

Share a verifier report or evidence bundle with a customer, partner, auditor, or internal reviewer.

Proof Gallery

A record should show exactly what can be trusted.

Originary packages the parts another party needs to verify independently: who issued the record, what policy and terms applied, what result was returned, and what the record does not claim.

Signed interaction recordVerified

Scenario

Paid API access event

x402 payment, access decision, policy version, terms digest, and API result are bound into one portable record.

Issuerapi.company.com

Policypolicy:v42

Terms digestsha256:93af...12d8

Payment referencex402:settled

Result hashsha256:b7f4...91ac

Signatureed25519:valid

Independent verifierOffline-capable

Issuer keymatches trusted JWKS

Policy bindingsame policy the requester saw

Terms bindingsame price and access terms

Result integrityresponse hash matches record

BoundaryThe record proves what was signed and bound. It does not claim the policy was fair, the output was correct, or payment finality beyond included settlement data.

API call proof

What happened: A pricing API returned a result under specific terms.
Who signed it: The issuer responsible for the API response.
Verifiable offline: Issuer, timestamp, policy digest, and result hash.
Does not claim: Does not decide whether the policy was commercially fair.

MCP tool call proof

What happened: An MCP server ran a tool with specific parameters.
Who signed it: The tool server, gateway, or issuing system.
Verifiable offline: Tool reference, parameters digest, output digest, and issuer signature.
Does not claim: Does not claim the tool output was objectively correct.

Commerce proof

What happened: An x402, MPP, AP2, Stripe, Visa, or Mastercard-linked access event was bound to transaction-local terms.
Who signed it: The commerce service or access gateway.
Verifiable offline: Terms digest, access decision, payment reference, and settlement context where provided.
Does not claim: Does not claim payment finality beyond the included record data.

Runtime decision proof

What happened: A runtime, gateway, or approval system attested a decision.
Who signed it: The runtime or approval system that issued the record.
Verifiable offline: Decision source, policy reference, action, and timestamp.
Does not claim: Does not replace your runtime controller or observability stack.

View sample records Verify one locally

Where Originary Fits

When another party needs proof, not just logs.

Verifiable API responses

For high-value API results where a customer may later ask what policy, terms, or result applied.

MCP and agent tool calls

For tool calls, parameters, outputs, approvals, and runtime decisions that need review outside the original system.

Commerce and x402 flows

For x402, MPP, AP2, Stripe, card-network, terms, access, and dispute evidence across agentic commerce flows.

Runtime governance and audit

For managed runtimes, policy systems, and approval paths that need exportable records.

How It Works

A record travels where logs cannot.

Your system emits an important API call, tool call, payment event, or runtime decision.

Originary binds relevant policy, terms, result, and metadata.

A signed interaction record is issued.

Another party verifies it independently.

PEAC

Built on PEAC. Usable through Originary.

PEAC is the open standard for portable signed interaction records. Originary gives teams a production path to issue, verify, and export those records for real deployments.

The standard stays open. Verification can remain independent. Records do not require trusting Originary's dashboard.

Open record format

Offline verification

Self-hostable reference path

Hosted operation available

No proprietary lock-in

View PEAC on GitHub Downloads

Capabilities

Use only the capability you need.

Verification

Hosted and local verification for signed records.

Review artifacts

Verifier reports and exportable evidence packages for customers, partners, and auditors.

Commerce proof

Payment, terms, and access proof for x402, MPP, AP2, Stripe, and card-network commerce flows.

Runtime records

Records for agent, API, MCP, and managed-runtime events.

Verifier Report

A signed record becomes a report another party can inspect.

The report is concrete: issuer, signature, policy binding, terms, record format, and verification mode are visible without relying on your internal dashboard.

Verification reportVerified

Statusverified

Issuervalid

Signaturevalid

Policy bindingverified

Terms digestmatched

Record formatPEAC

Verification modeoffline-capable

Trust

Designed for proof without lock-in.

Trust scores change. Signed records travel. Anyone can verify what happened without trusting your dashboard.

Records remain useful outside Originary.

Verification can happen independently.

Self-hosted and local verification paths remain available.

Records can be shared without exposing internal logs.

Privacy-aware verification avoids raw secret and personal-data leakage.

Good fit

You have one API, MCP, agent, runtime, or commerce flow where logs are not enough.
Another party needs to verify what happened.
You need a hosted or self-hosted path.
You want evidence that can travel beyond one dashboard.

Not a fit

You only need internal debugging.
No customer, partner, auditor, or second team needs the evidence.
You are not ready to instrument one concrete flow.
You need a policy engine, runtime controller, trust score, or observability dashboard.

Pilot

Start with one workflow.

Bring one API, MCP, commerce, or runtime flow. Originary will help make it signed, verifiable, and exportable without replacing your stack.

Pilot includes

One scoped flow
Record issuance path
Verification path
Exportable review artifact
Deployment recommendation

Start with one workflow Verify a sample record

FAQ

Frequently asked questions.

Do we need to replace our stack?

No. Originary is designed to sit around one concrete flow that already exists.

Is verification tied to Originary?

No. Records remain portable, and verification can stay independent.

Can we self-host?

Yes. Hosted and self-hosted deployment paths remain available.

Next Step

If one flow needs stronger proof, start there.

Logs stay local. Records cross boundaries. Bring one API, MCP, commerce, or runtime flow and start there.

Start with one workflow Verify a sample record