Back to projects07 / Agent tooling / provenance
RunLedger
RunLedger stores agent execution as append-only JSONL events linked by SHA-256, then verifies the chain and renders a human-readable run report.
The problem
When an autonomous run fails, normal console logs are often mutable, incomplete or scattered across providers. It can be difficult to establish what the agent actually called, retried, decided and returned.
How I approached it
- 01Write one structured event per line to a local JSONL ledger.
- 02Link every event to the previous event with SHA-256 so edits, deletion and reordering are detectable.
- 03Keep the core independent of any single model provider or agent framework.
- 04Render the same ledger into a readable HTML report without requiring a hosted observability service.
03 / WHAT SHIPPED
Key features
- Append-only JSONL events
- SHA-256 hash chain
- Tool-call and result events
- Decision and retry events
- Tamper verification
- Human-readable HTML reports
- No database required
- Local-first provenance
Architecture
- Runtime
- TypeScript · Node.js
- Storage
- JSONL
- Integrity
- SHA-256 hash chain
- Verification
- Deterministic chain check
- Output
- JSONL · HTML
- License
- MIT
What RUNLEDGER is built to preserve.
- Boring formats are durable
- Local evidence before hosted telemetry
- Every event should be independently inspectable
- Integrity checks should not depend on the agent that created the log
Useful answers, without the hunt.
Is RunLedger an observability SaaS?
No. The current core is a local primitive: JSONL, SHA-256 and an HTML renderer. Hosted export can be added later without changing the ledger model.
What does tamper-evident mean here?
Each event hash includes the previous event hash. Editing, removing or reordering a recorded event breaks subsequent verification.
Does RunLedger require a database?
No. The current core stores append-only JSONL locally and can verify and render that ledger without a database or hosted telemetry service.
