Make AI actions verifiable beyond your own logs.
Originary turns selected agent actions, API calls, MCP tool runs, gateway decisions, approvals, payments and provisioning changes into portable signed records. Compliance, risk, security and audit teams can verify what each issuing system reported without access to its private logs or dependence on an Originary service.
Supports evidence collection and review. It does not determine whether a legal, regulatory or contractual requirement is satisfied.
- Issuer
- gateway.example
- Action
- tools.call market_search
- Decision
- allow, policy v4
- Approval
- bound to proposal digest
- Time
- 2026-04-17T14:08:11Z
Policies describe what should happen. Logs show one operator what its system saw. A review needs something else.
When an AI action is reviewed, disputed or investigated, the relevant evidence is usually spread across agent runtimes, gateways, approval systems, observability tools, payment providers and internal databases. Each system has its own identifiers, retention rules and operator-controlled logs.
Originary creates a bounded handoff that another party can inspect, verify and retain.
Scattered
The approval, action, gateway decision, result and payment reference often live in different systems.
Locked inside the source
A dashboard or log export normally depends on the operator that produced it and the access it continues to provide.
Reconstructed after the fact
Audit and compliance teams spend time collecting screenshots, CSV files, tickets and explanations after a review has already begun.
Gaps are easy to hide
Traditional happy-path reports rarely distinguish evidence that is verified, merely linked, missing, conflicting or outside the review.
The evidence handoff between the systems that acted and the people who must review them.
Keep your agent framework, AI gateway, observability stack, SIEM, GRC system and approval workflows. Originary adds a portable evidence path across them.
- 01 Collect
Select only the records and native artifacts relevant to the reviewed action. Private logs remain in the systems that produced them.
- 02 Verify
Check signatures, record structure, bound digests, issuer information and the supplied verification-key or expected-issuer policy.
- 03 Assess
Show what the evidence establishes, what is missing, where sources conflict and which properties were not evaluated.
- 04 Hand off
Export the signed records, linked native artifacts, verification report and timeline so another party can inspect the same bounded case.
Capture the decisions and actions that matter to a review.
Agent and tool actions
Record which AI agent or tool acted, the relevant target, input or argument digest, reported result and time.
Approvals and human oversight
Bind an approval or denial to the exact proposal or action digest that was reviewed.
Gateway and access decisions
Record a terminal allow, deny or review decision together with the policy or check the gateway reported applying.
Payments and agent commerce
Connect service actions to authorization, mandate, payment and settlement references without inventing payment finality or delivery.
Provisioning and access changes
Preserve reported changes to accounts, resources, credentials, subscriptions and deployments.
Cross-system context
Carry trace references, native-provider artifacts, related-record identifiers and acknowledgements without replacing their original semantics.
Record only what a system actually observed. Do not infer events, authority, delivery or completeness that the source did not establish. An AI audit trail assembled this way shows what each issuer reported about the actions it recorded. It does not establish that every relevant event was recorded or that nothing was withheld.
One evidence case, with its limits stated.
An evidence case gives reviewers the selected records, issuer and key context, linked native artifacts, deterministic verification results and a timeline of the supplied evidence.
It does not turn an incomplete record set into a complete history. It makes the boundaries visible.
3 of 7 elements verified under the supplied key. One is linked, one is bounded, two were never supplied.
- Gateway decision
- signature verified
- Tool invocation
- signature verified
- Result content
- digest matches
- Payment-provider artifact
- linked
- Approval record
- not supplied
- Delivery
- not established
- Verification report
- complete with limitations
Illustrative evidence case. No customer, adoption or compliance claim.
Support the evidence work around AI governance and compliance frameworks.
Originary does not certify an AI system, interpret the law or determine that a control has been satisfied. It gives operators and reviewers portable, verifiable records that can support their own assessment.
EU AI Act
Support selected traceability, record-keeping and technical-documentation workflows with verifiable records of runtime events, decisions and oversight artifacts. Originary does not determine whether a system is high-risk or whether an obligation is satisfied.
ISO/IEC 42001
Support operational evidence for an AI management system, including selected controls, approvals, decisions, changes and reviews. The PEAC mapping is informative and is not certification.
NIST AI RMF
Preserve records that can support selected Govern, Map, Measure and Manage activities. Originary does not replace your AI risk-management process.
Framework applicability, evidence sufficiency and legal conclusions remain the responsibility of the organization and its qualified advisers, assessors or auditors.
Built for consequential AI actions, not routine event collection.
Internal audit and control review
Give reviewers a bounded record set for selected controls and actions without exposing the full operational log environment.
High-risk agent-action review
Connect the proposed action, approval or denial, execution record and reported result.
Incident investigation
Preserve the gateway decision, tool or API action, relevant artifacts and verification outcome for a later investigation.
Customer or counterparty assurance
Hand another organization records it can inspect locally under an explicit issuer-and-key policy.
Paid tool or API dispute
Connect authorization, service invocation, result commitment and native payment artifacts while stating whether delivery was actually observed.
Provisioning and access review
Verify reported account, credential, resource, deployment or subscription changes after the originating system is unavailable or inaccessible.
Not another governance dashboard.
| Question | Internal logs | Governance or GRC system | Originary evidence case |
|---|---|---|---|
| Primary job | Operate and debug a system | Manage policies, controls and review workflows | Hand off bounded, verifiable evidence |
| Verified outside the source system | Usually not independently | Varies by platform and export | Yes, under an explicit issuer-and-key policy |
| Requires private-system access | Usually | Often requires platform access | No, for the selected supplied records |
| Shows missing or conflicting evidence | Rarely | Varies | Explicitly |
| Replaces existing infrastructure | No | May be a primary workflow system | No, composes with both |
| Portability | Vendor or system specific | Varies | Open portable interaction records |
Originary complements your controls and systems. It does not decide which actions to permit, enforce policies or replace the process that determines compliance.
A valid record can still be insufficient evidence.
- the supplied key validates the signature;
- the protected record bytes were not changed;
- disclosed content matches the digests bound by the record;
- the record contains the issuer-reported claims shown.
- that every relevant event was recorded;
- that the issuer's observation was complete or truthful;
- that the supplied key was authorized by the claimed issuer;
- that delivery occurred;
- that a policy, legal or regulatory requirement was satisfied.
Expected-issuer and trusted-key policies can strengthen the verification context, but they do not convert an issuer's statement into independently established truth.
An open protocol underneath, independent verification by design.
PEAC Protocol is an Apache-2.0 open protocol for portable signed interaction records. Originary uses PEAC records to prepare and verify evidence cases, but teams can issue, verify, implement and self-host PEAC independently of Originary.
- Portable signed interaction records
- Offline verification
- Self-managed keys
- Independent implementations
- Conformance vectors
- No Originary callback required
Record locally. Verify across boundaries.
Common questions about AI compliance evidence.
- What is AI compliance evidence?
- AI compliance evidence is the set of records and artifacts a compliance, risk, security or audit team uses to assess an AI system or action. Originary focuses on making selected runtime actions and decisions portable and independently verifiable, while stating what the supplied evidence does not establish.
- Is Originary an AI governance platform?
- No. Governance and control platforms define, apply or manage policies and workflows. Originary prepares and verifies evidence from the systems that observed an action so that another party can review the same bounded record set.
- Does Originary make an AI system compliant?
- No. Originary does not interpret laws, certify systems or determine that a requirement has been satisfied. It can support a compliance assessment by providing verifiable records and explicit evidence limitations.
- Does this replace logs, observability or a SIEM?
- No. Logs and telemetry remain essential for operating and debugging systems. Originary selects and packages the records another party needs to verify outside the source environment.
- Can records be verified without Originary?
- Yes. PEAC records are designed for independent and offline verification. Verification should use an explicit key or expected-issuer policy appropriate to the review.
- Does a signed record prove that an action really happened?
- A valid signature shows that the protected record was signed under the supplied key and was not changed afterward. It does not, by itself, prove that the issuer's observation was complete or truthful, that every relevant event was recorded or that delivery occurred.
- How does PEAC Protocol relate to Originary?
- PEAC Protocol defines the open record and verification foundation. Originary develops software and workflows for issuing, collecting, verifying, assessing and handing off those records across organizational boundaries.
Bring one workflow. We will identify what your systems can honestly record, what a separate reviewer can verify, and what evidence would remain missing.
Start with one consequential AI workflow.
Bring one agent action, gateway decision, approval, paid tool or API call, incident, or provisioning change. We will identify what your systems can honestly record, what a separate reviewer can verify and what evidence would remain missing.
Related reading: what an evidence case contains, audit and incident handoff, and deployment and verification boundaries.