HOW IT WORKS
The mechanics of an audit trail for autonomous AI.
RANKIGI runs as a passive sidecar. It receives recorded actions your agents take, hashes them, chains them, and produces a tamper-evident record. Your agents do not change. Your latency does not change. The audit trail appears.
DEFINITION
RANKIGI is a passive observability sidecar that ingests agent actions over HTTPS, hashes each event with SHA-256, chains it to the previous event hash, and produces an append-only ledger that is independently verifiable.
THE PROBLEMS IT SOLVES
What goes wrong without it.
01
Agents act. Logs do not survive scrutiny.
Application logs are mutable. They live in systems that allow UPDATE and DELETE. When an auditor or regulator asks for proof, plain logs are not enough. They cannot demonstrate that nothing was altered.
02
There is no native chain of custody.
An agent that calls a tool, generates an output, and triggers a second agent leaves a trail scattered across services. There is no single ordered record that proves the sequence happened the way it appears to have happened.
03
Compliance teams ask for evidence engineers cannot produce.
SOC 2, the EU AI Act, and HIPAA all require evidence of automated decision provenance. Most agent systems were not designed to produce this evidence. RANKIGI was.
HOW IT WORKS · TECHNICAL
The pipeline, end to end.
01 INGEST
POST /api/ingest
Your agent or SDK sends each action to /api/ingest as a signed JSON payload over HTTPS. Authentication is a Bearer token tied to your organization. The endpoint is non-blocking. If RANKIGI is unreachable the agent continues and events are queued.
02 HASH
Canonical JSON, SHA-256
The event payload is canonicalized (deterministic key ordering, no whitespace) and hashed with SHA-256. The hash is the event_hash. The same payload always produces the same hash, so any third party can recompute it.
03 CHAIN
previous_event_hash
Each event records the previous_event_hash for that agent. The chain is per-agent and append-only. Altering any past event changes its hash, which breaks every subsequent link. Tampering is mathematically detectable.
04 STORE
Append-only event store
Events are written to Postgres with row-level security. The events table has no UPDATE or DELETE permissions for any role. Daily snapshots are anchored to an external authority for an additional layer of evidence.
05 VERIFY
GET /api/chain/verify
Anyone with a valid token can request a chain verification. RANKIGI walks the chain, recomputes every hash, and returns a pass/fail with the exact event index of any break. Verification is deterministic and reproducible.
06 EXPORT
Compliance evidence package
On demand, RANKIGI produces a signed evidence bundle for a date range or an agent. The bundle contains the canonical events, the hash chain, the snapshot anchors, and a signed manifest. It is suitable for auditors and for legal proceedings.
HOW IT WORKS · PLAIN ENGLISH
In plain English.
Imagine your agent is a notary that stamps a record of recorded actions it takes. The stamp is a fingerprint of what it did, and each new stamp is glued to the previous one with a thread that cannot be cut without leaving a visible scar. RANKIGI is the notary. Your agent does the work. RANKIGI watches and stamps. If anyone ever tries to change the past, the scar is visible immediately. That is the entire mechanism.
ANALOGY
Think of it as the flight data recorder. The plane keeps flying. The recorder keeps recording. When something goes wrong, the recording is what investigators trust, because it was never editable in the first place.
ANATOMY
The shape of an event.
The core event
Recorded actions your agent takes become events. The fields below are the minimum every event carries.
The verification response
A successful verify returns the chain length, the head hash, and a pass status. Any break returns the exact index where the chain failed.
TRANSPORT SCOPE
What we capture, and what we do not.
CAPTURED
Out of the box, no SDK changes.
- All outbound HTTP calls
- All outbound HTTPS calls
- Request headers and method
- Response status and body hash
- Timing and latency
NOT CAPTURED (REQUIRES SDK)
Non-HTTP transports require the SDK.
- gRPC over custom transports
- Database-direct TCP connections
- stdio-based tool protocols
- Local process invocations
- UDP traffic
For full-spectrum capture combine the proxy with the RANKIGI SDK. Both submit to the same chain under the same agent passport.
REGULATION MAPPING
What auditors actually ask for.
| Framework | Reference | Requirement | RANKIGI Answer |
|---|---|---|---|
| SOC 2 | CC7.2 / CC7.3 | Evidence of system monitoring and detection of unauthorized changes. | Hash chain verify endpoint returns deterministic proof of integrity per agent. |
| EU AI Act | Article 12 | Automated logging of events for traceability of high-risk AI systems. | Recorded actions are captured by the sidecar with timestamp, input hash, and output hash. |
| EU AI Act | Article 13 | Transparency of automated decision processes. | Compliance export bundle reconstructs the full deliberation and decision chain. |
| HIPAA | 164.312(b) | Audit controls that record and examine activity in systems containing ePHI. | Append-only event store with no UPDATE or DELETE on the events table. |
WHO IT IS FOR
Who needs to understand the pipeline.
DEVELOPER
You integrate the SDK or call /api/ingest directly. The pattern is fire-and-forget. The sidecar never blocks your agent. You get an event_id back. That is the contract.
- +under 200ms p95
- +fire-and-forget
- +TypeScript and Python SDKs
COMPLIANCE OFFICER
You receive evidence on demand. Date range or agent scope. The bundle is signed, contains the chain, and stands on its own in front of an auditor. You do not need engineering to produce it.
SECURITY ENGINEER
You verify the chain on a schedule. You alert on any break. You confirm that snapshots are anchored. RANKIGI gives you the primitives. You decide the cadence.
QUESTIONS & ANSWERS
How engineers and auditors actually probe this.
What happens if RANKIGI is down when my agent acts?
The agent keeps running. The SDK queues events locally and replays when the sidecar is reachable. RANKIGI is non-blocking by design because an audit system that can stop production is an audit system that gets disabled.
How do I know the hash chain has not been tampered with?
Call GET /api/chain/verify. RANKIGI walks the chain, recomputes every hash from canonical JSON, and either returns pass with the head hash or fail with the exact event index where the chain broke. The check is deterministic and you can run it from any client.
Where does the data live and who can read it?
Events are stored in Postgres with row-level security scoped to your organization. Only members of your org can read them. RANKIGI staff cannot access tenant data without an explicit support handshake that is itself logged.
What is the latency overhead?
Ingestion target is under 200ms p95. The SDK fires events asynchronously, so the synchronous overhead on your agent is the time to enqueue, which is sub-millisecond.
Can the chain be exported and verified by a third party?
Yes. The compliance export contains canonical events and the snapshot anchors. Any party with the bundle can recompute the hashes and confirm the chain without contacting RANKIGI.
We will walk through your agent stack and show where the chain attaches.
Pipe your first event into the chain in under ten minutes.