RANKIGI seals a cryptographic receipt for every byte of data your agent touched, every action it took, and every output it produced. Hash-chained, Ed25519-signed, verifiable offline by your regulator.
A record you can inspect, not a dashboard you have to trust.
Each row is a sample receipt from a deterministic demo chain: action, timestamp, hash, and anchor status. It mirrors the proof artifact a reviewer inspects during verification.
CHAIN #184402026-06-04 14:22:07 UTC
tool_call: postgres.query
a1b2c3d4e5f60718293a4b5c...
agent-supply-chain-01REKOR ANCHORED
CHAIN #184412026-06-04 14:22:10 UTC
tool_call: fetch_url
b2c3d4e5f60718293a4b5c6d...
agent-research-04REKOR ANCHORED
CHAIN #184422026-06-04 14:22:13 UTC
tool_call: kubernetes.apply
c3d4e5f60718293a4b5c6d7e...
agent-ops-02REKOR ANCHORED
CHAIN #184432026-06-04 14:22:16 UTC
tool_call: stripe.refund
d4e5f60718293a4b5c6d7e8f...
agent-billing-09REKOR ANCHORED
CHAIN #184442026-06-04 14:22:19 UTC
tool_call: zendesk.update_ticket
e5f60718293a4b5c6d7e8f90...
agent-support-03REKOR ANCHORED
CHAIN #184452026-06-04 14:22:22 UTC
tool_call: github.create_release
f60718293a4b5c6d7e8f9012...
agent-deploy-07ANCHOR PENDING
Logs are produced by the system they describe.
RANKIGI sits outside the agent path as a witness. It turns submitted actions into receipts that can be checked by someone who does not trust your dashboard.
WITHOUT RANKIGI
Logs can be edited by anyone with write access
Timestamps come from the system being observed
Auditors need your explanation of what happened
Vendor-specific format locked to the platform
Trust is assumed, not verified
WITH RANKIGI
Events are hash-chained, append-only, tamper-evident
Time is anchored to RFC 3161 and Sigstore Rekor
Auditors get a receipt they can verify independently
RCR/1 open format, verifiable without RANKIGI
Trust is constructed from cryptographic primitives
HOW THE PROOF IS BUILT
Five steps from action to evidence.
RANKIGI does not ask a buyer to trust a dashboard screenshot. It emits records with enough structure to be checked again later.
01
Witness
The agent emits an action through the SDK or provider shim.
agent_id + action + occurred_at
02
Hash
The canonical event is reduced to a SHA-256 fingerprint.
event_hash = SHA-256(canon)
03
Chain
The event binds to the previous hash, making edits detectable.
prev_hash -> event_hash
04
Anchor
Snapshot roots are timestamped and submitted to public transparency infrastructure.
RFC 3161 + Sigstore Rekor
05
Verify
Anyone can recompute the chain from the exported receipt bundle.
verify.py --bundle receipt.json
ENTERPRISE TRUST
Three guarantees. No hand-waving.
TAMPER-EVIDENT
SHA-256 hash chain, append-only
Every action is canonicalized, hashed, and bound to the previous event hash. Any modification breaks the chain at the next verification, so silent edits become detectable in seconds.
INDEPENDENTLY VERIFIABLE
Anchored to Sigstore Rekor and RFC 3161
Snapshot roots are signed with Ed25519, RFC 3161 timestamped, and submitted to Sigstore Rekor when the anchoring cron runs. Anyone can re-verify the chain offline.
EVIDENTIARY POSTURE
Open standard, no vendor lock-in
Receipts are emitted in RCR/1 canonical form (IETF draft-snow-rcr-receipt-00). Verification works without RANKIGI infrastructure. FRE 902(14) caveat: qualified person testimony still required.
Bring one agent action. Leave with proof.
Developers can seal a receipt today. Enterprise teams can review the proof packet before a regulated pilot.
SOC 2 controls implemented (Type II in progress) · HIPAA BAA available (controls implemented) · EU AI Act evidence mapping available · FRE 902(14) evidentiary posture documented (qualified person required)