PROJECT / 07 · 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.

Concept artwork for RunLedger
01sha25602sha25603sha25604sha25605sha25606sha256
WHY THIS NEEDED TO EXIST

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 BUILT AROUND IT
01

Write one structured event per line to a local JSONL ledger.

02

Link every event to the previous event with SHA-256 so edits, deletion and reordering are detectable.

03

Keep the core independent of any single model provider or agent framework.

04

Render the same ledger into a readable HTML report without requiring a hosted observability service.

CAPABILITIES

What it does,
without the theatre.

01Append-only JSONL events02SHA-256 hash chain03Tool-call and result events04Decision and retry events05Tamper verification06Human-readable HTML reports07No database required08Local-first provenance
ARCHITECTURE

What the system is meant to preserve.

  1. 01Boring formats are durable
  2. 02Local evidence before hosted telemetry
  3. 03Every event should be independently inspectable
  4. 04Integrity checks should not depend on the agent that created the log
USEFUL ANSWERS
Does it require a hosted observability service?+

No. The current core is a local primitive: JSONL, SHA-256 and an HTML renderer.

How does tamper detection work?+

Each event hash includes the previous event hash. Editing, removing or reordering a recorded event breaks subsequent verification.

Does it need a database?+

No. The core stores append-only JSONL locally and can verify and render it without a database.

NEXT BUILD / 08

ActionMesh

Typed TypeScript action contracts for AI tools, MCP-style calls, HTTP and CLI with shared Zod validation, errors and retry semantics.

↗