ORIGINARY VERIFY

Signed records for machine actions across company boundaries.

Issue portable signed records when APIs, agents, MCP tools, gateways, payment flows, and provisioning systems act. Customers, partners, and auditors can verify those records without access to your private logs or dashboards.

Verify a sampleDiscuss a workflow

Built on PEAC Protocol · Apache-2.0 · Offline verification

Originary records selected facts from a local system action, signs the record, and lets anyone verify it outside the system that created it. Verification supports audit, compliance review, dispute evidence, and partner handoff.

  1. API call
  2. MCP tool run
  3. Agent action
  4. Gateway decision
  5. Payment event
  6. Provisioning event
  1. Counterparty verifiesonline
  2. Auditor reviewscompliance
  3. Bundle exportsportable

Logs stay local. Signed records travel.

  • v0.16.2 current release
  • 12,666 tests
  • 290 conformance checks
  • 36 packages on npm
  • Apache-2.0 licensed

Designed to fit with the stack you already use

  • MCP
  • x402
  • Stripe
  • A2A
  • Cloudflare
  • AP2
  • Vercel
  • MPP
  • OpenTelemetry
  • LangChain

Names and logos identify interoperability surfaces. No partnership, certification, or endorsement is implied.

where logs fail

Logs stop at your boundary.

API calls, agent runs, gateway decisions, payments, and provisioning events happen inside your systems. Originary lets you share signed records without exposing internal logs.

Company A
Company B
company boundary
local logs
operator log
14:08:11 POST /v1/search 200
telemetry
span 7bc2 latency=412ms
dashboard
metric usage.api +1
trace
parent.span = a4f1d
logs stop here
Logs help operators debug. Records give counterparties something they can verify.
the product

One product system: Record, Verify, Bundle.

Originary Verify covers the full evidence path: issue a signed record where the action happens, verify it anywhere, and assemble records into evidence when someone asks what happened.

01RecordCapture selected facts at the workflow boundary and issue a compact, signed record. Private logs stay private.How records are issued02VerifyCheck the signature, issuer, policy context, and result independently. Offline by design; no account, no callback.Verify a sample03BundlePackage related records and supporting evidence for disputes, audits, procurement, and partner review.Evidence bundles
where it fits

One record format. Many places to verify.

Use the same signed-record primitive across agent actions, MCP tools, gateways, payments, provisioning, audits, and partner reviews.

Agent actions

proof question

What did the agent decide, and which inputs and policy was that decision bound to?

MCP tools

proof question

Which tool was called, under what policy, and what result did the tool return?

Gateway decisions

proof question

What happened at the boundary before the request was routed, throttled, or refused?

Payment events

proof question

What was authorized, captured, refunded, or settled, and against which mandate?

Provisioning

proof question

Which account, resource, credential, or subscription event occurred, and who issued it?

Audit and partner review

proof question

Can a customer, auditor, or partner verify what happened without internal access?

shared verification rail

Different workflows. Same portable record format.

ecosystem fit

Common places Originary records fit.

Examples are interoperability surfaces, not partnership claims. Use the same signed-record format wherever another party needs to verify what happened.

start small

Start with one workflow. Expand when proof matters.

Most teams start with one workflow where external proof is already painful: a customer-facing API, an agent action, a gateway decision, a payment event, or an audit request.

01
One workflow
Pick a workflow where another party already asks, "What happened?"
02
Record issued
Originary creates signed records from selected workflow facts.
03
Review begins
Share records with a customer, auditor, partner, or internal reviewer.
04
Expand when useful
Add more workflows only when the proof boundary matters.
see it on your workflow
Get started

Start with one workflow where proof already matters.

Send one API call, MCP tool run, agent action, gateway decision, payment event, or provisioning workflow. We’ll show what a signed record could look like.

  • Agent action
  • Customer dispute
  • MCP tool run
  • Procurement review
  • Payment or gateway event
Tell us the workflow that needs verification.

Sent to the team and routed by topic; falls back to an email draft to contact@originary.xyz if submission is unavailable. Business contact details only; never paste records, JWS strings, or keys. We use what you send only to route your message and reply, and retain it no longer than needed for that. See our privacy policy.