For security and risk leaders

The gap

No existing tool records what an agent was permitted to do, intended to do, and actually did.

Identity & access

Grants access — not records

IAM decides whether an agent can reach a resource. It does not record what the agent did once it got there. The access decision is logged; the action is not.

Model-judged controls

Cannot be reproduced

Same input, different output. Temperature, context drift, and prompt variation change decisions. Under review, "the model decided it was allowed" does not hold.

Observability

Knows what happened — not what was permitted

Monitoring and tracing platforms ingest events and produce dashboards. They show what a service did, not what an agent was authorized and intended to do.

The requirement
A deterministic, signed, verifiable record.

The gap is a deterministic policy engine, a canonical signed format, and a reviewable decision history that survives independent scrutiny.

The product

An append-only log of cryptographically signed receipts, a deterministic policy engine, and a query interface for review, evidence, and policy iteration.

post-action.receipt
Verified
{ "receipt_version": "0.1", "receipt_type": "post-action", "agent_id": "agent_7f3a9c", "action_type": "http_request", "terms_url": "api.example.com/v2", "terms_hash": "sha256:a1b2c3…", "decision": "allow", "timestamp": "2026-05-18T10:32Z", "post_state_hash": "sha256:f6e5d4…" }

Every action, before and after. Each action produces a pre-action receipt before it executes and a post-action receipt after it completes. The post-action receipt commits the hash of what the agent actually did — not only what it intended. Both conform to ORS v0.1.

01

Cryptographically signed receipts

Every receipt carries an Ed25519 signature. The record of agent action is committed at the moment it happens, not reconstructed later.

02

Deterministic policy decisions

Decisions are allow, deny, or escalate. The same policy version and receipt pair always produces the same decision — reproducible and explainable. No LLM in the evaluation path.

03

Independent third-party verification

Every receipt is verifiable against the issuer's public key, published at the JWKS endpoint per RFC 7517. Verification requires no API call to OpenTerms.

04

Simulation before deployment

Test candidate policy changes against the historical receipt corpus before activating them. See which decisions would have differed, and why, before a policy goes live.

05

Reviewable action history

A queryable, append-only history of decisions for incident review, counterparty review, and policy iteration — structured for the people who later need to reconstruct what happened.

06

SDK instrumentation

Emit receipts from your agent code with a single function call. Python and TypeScript SDKs, with LangChain and CrewAI adapters that wrap tool calls.

Built on ORS — not on proprietary primitives

The Open Receipt Specification v0.1 is published on GitHub. Receipts issued by OpenTerms conform to the same specification as receipts issued by any other compatible implementation. The format does not lock you into the OpenTerms service.

View ORS specification →
RFC 8785

JSON Canonicalization Scheme — deterministic serialization before signing.

Ed25519

Signing path with domain separation for every receipt.

RFC 7517

JWKS distribution. Replace OpenTerms and receipts stay verifiable against the public key history.

Canonicalization rules and test vectors published for any implementer to conform against.

On readiness. Observe provides audit-oriented, reviewable action history. Formal audit-readiness claims are reserved for surfaces backed by the corresponding operational controls.

Private beta · Access by application

Build the record before you need it. Observe is in private beta. Access is by application. The ORS specification, the receipt format, and the verifier are open today.